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

Re: parsing and comparing URIs

McDonald, Ira wrote:

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.


We will never issue a standard URI for use with NETCONF that has
any special fields or encodings.  (I know the URI syntax allows it though)
Because the spec is silent on this issue, it implies that all the normalization 
rules must be supported by a NETCONF implementation.

<rant>
We just wanted simple capability strings and we were forced by the IESG to use the verbose URN scheme instead. There is no real need to support any of the normalization complexity. The WG does not 
want to encode NETCONF-related semantics into these capability URIs.
They are only to be used for comparing the entire value.
They are conceptually equivalent to Registration OBJECT IDENTIFIERs in SMIv2.
It is very annoying that we are forced to accept massive complexity without value, for reasons I won't even guess at. 
Good Engineering means keeping protocol mechanisms as simple as possible.
(An idea lost on the IETF many years ago...)
</rant>


Andy



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/>