RE: parsing and comparing URIs

["McDonald, Ira" <imcdonald@sharplabs.com>]

Hi Andy,

I totally agree with you - thus we should decide and specify
that the namespace URIs used in any conformant Netconf
implementation MUST be specified entirely without hex escapes
in absolutely plain ASCII and avoid all normalization
(remembering that after the host name, URIs _are_ case
sensitive, so choosing lowercase might be a good idea).

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: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Thursday, March 22, 2007 12:49 PM
To: McDonald, Ira
Cc: netconf
Subject: 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


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