Re: parsing and comparing URIs

[Martin Bjorklund <mbj@tail-f.com>]

Andy Bierman <ietf@andybierman.com> wrote:
> 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.

So, since this was clearly not the intentation, can't we put this on
the list of clarifications for the next revision of the base protocol?

But there is actually one URI which you have to parse - the uri for
the :url capability encodes which url schemes are supported in the
uri:

      urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file

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

I agree.


/martin

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