Subject: parsing and comparing URIs

From: Andy Bierman <[email-masked]>
Date: Wed, 21 Mar 2007 18:18:40 -0700

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 22 Mar 2007 10:33:27 -0700

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: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Andy Bierman
Sent: Wednesday, March 21, 2007 8:19 PM
To: netconf
Subject: parsing and comparing URIs

Hi,

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Mar 2007 10:48:44 -0700

> then this would be okay, but we have to use the 'urn' scheme, so that

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 22 Mar 2007 20:48:21 +0100 (CET)

> 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

> (An idea lost on the IETF many years ago...)

I agree.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 22 Mar 2007 22:02:36 +0100 (CET)

Also note http://www.w3.org/TR/REC-xml-names/#dt-identical which says
that when these URIs are used as namespace identifiers, they should
NOT be normalized (as defined by rfc 3986):

  Definition: The two URIs are treated as strings, and they are
  identical if and only if the strings are identical, that is, if they
  are the same sequence of characters.

  [...]

  Examples:

    The URI references below are all different for the purposes of
    identifying namespaces, since they differ in case:

      * http://www.example.org/wine
      * http://www.Example.org/wine
      * http://www.example.org/Wine 

/martin

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 22 Mar 2007 15:40:59 -0700

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

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]]
Sent: Thursday, March 22, 2007 12:49 PM
To: McDonald, Ira
Cc: netconf
Subject: Re: parsing and comparing URIs

<rant>

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 23 Mar 2007 09:24:38 -0500

>of normalization required for those comparisons.

It also says:

   Normalization of the base and target URIs prior to their comparison,
   as described in Sections 6.2.2 and 6.2.3, is allowed but rarely
   performed in practice.

Thanks,
 Phil

---

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 23 Mar 2007 08:04:51 -0700

Hi Phil, Andy, et al,

Fine - do no normalization, but expect breakage unless
you have very fine-grained control of your tools chain.

Comparing URIs is not just "somebody else's problem".

And PARSING URIs is just plain unwise and certainly
dangerous unless normalization is performed.

Cheers,
- Ira

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]]
Sent: Friday, March 23, 2007 9:25 AM
To: McDonald, Ira
Cc: Andy Bierman; netconf
Subject: Re: parsing and comparing URIs 

It also says:

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Mar 2007 09:23:27 -0700

> you have very fine-grained control of your tools chain.

-----

6.2.1. Simple String Comparison

If two URIs, when considered as character strings, are identical, then 
it is safe to conclude that they are equivalent.
This type of equivalence test has very low computational cost and is in 
wide use in a variety of applications,
particularly in the domain of parsing.

------

I don't see why we have to do normalization, except to
support obscure encodings of capability URIs, which
nobody wants to do.  Even if an agent developer was crazy
enough to use these encodings, it would still be safe for
a manager to use the full string (provided by the agent vendor)
for comparison.

Andy