Subject: [urn] text about equivalence in 2141bis and 3406bis

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Jul 2013 17:35:44 -0600

I propose the following changes in 2141bis and 3406bis.

1. Remove Section 7...

OLD

7. Functional Equivalence in URNs

   Functional equivalence is determined within a given namespace and
   managed by resolvers for that namespace, and thus is beyond the scope
   of this document.  For related considerations with regard to NID
   registration, see [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg].

NEW

[nothing]

2. Change "lexical equivalence" to "equivalence"...

OLD

6. Lexical Equivalence in URNs

6.1. Procedure

   For various purposes such as caching, often it is desirable to
   determine if two URNs are "the same".  This is done by testing for
   "lexical equivalence".

   Two URNs are lexically equivalent if they are octet-by-octet equal
   after applying case normalization (as specified in Section 6.2.2.1 of
   [RFC3986]) to the following constructs:

   1.  the URI scheme "urn"
   2.  the NID
   3.  any percent-encoded characters (see Section 2.1 of [RFC3986])

   Percent-encoded characters MUST NOT be decoded, i.e., percent-
   encoding normalization (as specified in Section 6.2.2.2 of [RFC3986])
   MUST NOT be applied.

   If a query component, fragment identifier component, or both have
   been appended to the assigned URI, they MUST be ignored for purposes
   of determining lexical equivalence.

   URN namespaces MAY define additional rules for lexical equivalence,
   such as case-insensitivity of the NSS (or parts thereof).  Such rules
   MUST always have the effect of eliminating some of the false
   negatives obtained by the procedure above and MUST NOT result in
   treating two URNs as not equivalent if the procedure here says they
   are equivalent.  For related considerations with regard to NID
   registration, see [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg].

6.2. Examples

   The following URN comparisons (which use the "example" NID defined in
   [RFC6963]) highlight the lexical equivalence rules:

   1.  URN:example:a123,456
   2.  urn:example:a123,456
   3.  urn:EXAMPLE:a123,456
   4.  urn:example:A123,456
   5.  urn:example:a123%2C456
   6.  URN:EXAMPLE:a123%2c456

   URNs 1, 2, and 3 are lexically equivalent.  URN 4 is not lexically
   equivalent to any of the other URNs in the above set.  URNs 5 and 6
   are lexically equivalent only to each other.

NEW

6. Equivalence of URNs

6.1. Procedure

   For various purposes such as caching, often it is desirable to
   determine if two URNs are "the same".  This is done by testing for
   "equivalence" (see Section 6.1 of [RFC3986]).

   Two URNs are equivalent if they are octet-by-octet equal after
   applying case normalization (as specified in Section 6.2.2.1 of
   [RFC3986]) to the following constructs:

   1.  the URI scheme "urn"
   2.  the NID
   3.  any percent-encoded characters (see Section 2.1 of [RFC3986])

   Percent-encoded characters MUST NOT be decoded, i.e., percent-
   encoding normalization (as specified in Section 6.2.2.2 of [RFC3986])
   MUST NOT be applied.

   If a query component, fragment identifier component, or both have
   been appended to the assigned URI, they MUST be ignored for purposes
   of determining lexical equivalence.

   URN namespaces MAY define additional rules for equivalence, such as
   case-insensitivity of the NSS (or parts thereof).  Such rules MUST
   always have the effect of eliminating some of the false negatives
   obtained by the procedure above and MUST NOT result in treating two
   URNs as not equivalent if the procedure here says they are
   equivalent.  For related considerations with regard to NID
   registration, see [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg].

6.2. Examples

   The following URN comparisons (which use the "example" NID defined in
   [RFC6963]) highlight the equivalence rules:

   1.  URN:example:a123,456
   2.  urn:example:a123,456
   3.  urn:EXAMPLE:a123,456
   4.  urn:example:A123,456
   5.  urn:example:a123%2C456
   6.  URN:EXAMPLE:a123%2c456

   URNs 1, 2, and 3 are equivalent.  URN 4 is not equivalent to any of
   the other URNs in the above set.  URNs 5 and 6 are equivalent only
   to each other.

3. We would also need to make associated changes in 3406bis...

a. Section 5.1.2

OLD

   Third, the "Security Considerations" section describes any potential
   security-related issues with regard to assignment, use, and
   resolution of identifiers within the namespace.  Examples of such
   issues include the consequences of producing false negatives and
   false positives during comparison for lexical equivalence (see also
   [RFC6943]), leakage of private information when identifiers are
   communicated on the public Internet, the potential for directory
   harvesting, and the issues discussed in [RFC3552].

NEW

   Third, the "Security Considerations" section describes any potential
   security-related issues with regard to assignment, use, and
   resolution of identifiers within the namespace.  Examples of such
   issues include the consequences of producing false negatives and
   false positives during comparison for equivalence (see also
   [RFC6943]), leakage of private information when identifiers are
   communicated on the public Internet, the potential for directory
   harvesting, and the issues discussed in [RFC3552].

b. Section 7

OLD

     Rules for lexical equivalence:

NEW

     Rules for equivalence:

Peter

-- 
Peter Saint-Andre
https://stpeter.im/