Re: [urn] Expert review needed

[[e-mail] (Dale R. Worley)]

[e-mail] (Dale R. Worley) writes:
> Comments on draft-atarius-dispatch-meid-urn-14:

> If you allow that future changes will only be done via RFC, then you
> can omit all mention of future-pp2-specifier in this RFC, as they will
> be defined in later RFCs.  That could allow you to simplify this RFC
> considerably (especially the ABNF), as it would only have to deal with
> the one identifier class ("meid") that has already been defined.

Thinking about this more, it seems to me that it might be better to
modify the grammar in this way:

[as before]
   pp2-NSS              = meid-specifier / future-pp2-specifier
   meid-specifier       = "meid:" meidval

[changed]
   future-pp2-specifier = future-specifier [ ":" 1*( pchar / "/" ) ]
   future-specifier     = 1*pp2-char
   pp2-char             = ALPHA / DIGIT / "-" / "." / "_" / "%"
                                           
[unchanged]
   ALPHA                = %x41-5A / %x61-7A; A-Z / a-z
   DIGIT                = %x30-39; 0-9

[removed]
   future-param         = par-name [ EQUAL par-value ]
   par-name             = pp2-defined-nonempty
   par-value            = pp2-defined-nonempty
   EQUAL                = "="
   pp2-defined-nonempty = 1*pp2-urn-char

This is more general than the current grammar regarding the format of
<future-pp2-specifier>, it's only slightly stricter than RFC 8141's
generic rules for NSSs.  But it allows you to call out that
<future-ppp2-specifier> starts with <future-specifier> (up to the first
":", or if no ":", to the end), and in the text you can say that
<future-specifier> can't be "meid".  That preserves the nice
"sub-namespace" structure that you've defined, without restricting the
syntax of the latter part of the NSS for non-meid sub-namespaces.  (Any
actual sub-namespace will be defined by a later document which will give
the (likely narrower) grammar for the sub-namespace.)

----------

I think these sections need work:

   4.1.  MEID Parameters

   ...

   Rules for Lexical Equivalence:

   Two 3GPP2 MEID URNs are equivalent if they have the same 'meidval'
   and the same parameter values in the same sequential order.  All of
   these comparisons are to be case-insensitive.

   Any identifier in '3gpp2' NSS can be compared using the normal
   mechanisms for percent-encoded UTF-8 strings (see [RFC3629]).

It's not clear what "MEID parameters" are, since the grammar explicitly
forbids parameters in the MEID sub-namespace.  And the first paragraph
of 4.1 simply says that any change to what is specified in this document
must be via an RFC -- which is true anyway because this will be any RFC.

The first paragraph of "Rules for Lexical Equivalence" talks of
parameter values for 3gpp2:meid URNs, but there are no such parameters.

The first paragraph of "Rules for Lexical Equivalence" also says that
3gpp2:meid URNs are to be compared case-insensitively, but the grammar
allows no variance of case within the NSS:  "meid" is lower case and
<meidval> is upper case.

The second paragraph of "Rules for Lexical Equivalence" says that all
3gpp2 URNs can be compared "using the normal mechanisms for
percent-encoded UTF-8 strings", which is implicitly case-sensitive.

Dale