[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: parsing and comparing URIs



Hi Andy,

Actually, you can't safely compare URIs at all unless
you subject them both to normalization and (as RFC
3986 clearly says) a given protocol that depends on
comparison of URIs must precisely specify the steps
of normalization required for those comparisons.

Netconf can't and shouldn't punt on this - if equivalance
of namespaces matters (and it obviously does) then the
onus is on the Netconf protocol specs to specify it (or
to reference an IETF or W3C specification that specifies
the chosen method).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
Behalf Of Andy Bierman
Sent: Wednesday, March 21, 2007 8:19 PM
To: netconf
Subject: parsing and comparing URIs


Hi,

I re-read RFC 3986, and it doesn't really say not to parse URIs.
Section 6.2.1 says it is safe to compare 2 URIs as strings.
However, the rules for Normalization and Comparison (sec. 6)
are quite complicated.  I seriously doubt any NETCONF implementation
is following these rules.  RFC 4741 is silent wrt/ normalization.
I need to read more about the URN scheme, which may impose
some constraints on various encodings that would require normalization.

We did not really resolve the 1, 2, or 3 namespace issue wrt/ 
notification draft,
but it seems clear to me that we were ready to agree on 2 namespaces
(1 for <create-subscription> and <notification>, and the other for the 
data model content).

IMO, it is fine to use this convention of a separate namespace for content,
but we should not try to parse NETCONF URIs for some field that
differentiates between protocol operation and protocol content.
If we defined our own scheme with these specific semantics built-in
then this would be okay, but we have to use the 'urn' scheme, so that
is not an option.

Andy


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.17/730 - Release Date: 3/22/2007 7:44 AM
 

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>