Subject: Re: [urn] Expert review needed

From: [email-masked] (Dale R. Worley)
Date: Sat, 10 Mar 2018 10:23:03 -0500

My apologies for losing track of this.

R Atarius <[email-masked]> writes:
> Hi Dale,
> I have segmented your comments by adding
> ******************************************************* line
> and the second comment that you had on the first comment, is marked by 
> ---------------------------------------------------------------- line
>
> My comments and proposed text are marked by <Roozbeh>
> ThanksRoozbeh

The text version of your e-mail didn't come through very well.  I've had
to reformat it to reply to it.

Just to verify:  It looks like few of these changes were incorporated
into the -15 version.

There are an array of wording changes that you've made.  They take care
of most of the items I pointed out, with the exception of the few that I
mention below.

>> As far as I can tell, the MEID check digit is "not transmitted" in
>> thesense that it's not part of the URN itself.  [...]

> <Roozbeh> How about having this in two sections:

Your new language makes this matter clear.

> Dale's INITIAL COMMENT:
>> If you allow that future changes will only be done via RFC, then
>> youcan omit all mention of future-pp2-specifier in this RFC, as they
>> willbe defined in later RFCs.  That could allow you to simplify this
>> RFCconsiderably (especially the ABNF), as it would only have to deal
>> withthe one identifier class ("meid") that has already been defined.

> <Roozbeh>:This draft was initially written to be aligned with the text
> inRFC 7254. In that document the future changes  were introduced and
> that is the reason this document also contains
> those.

OK, I can see the value in aligning with 7254.

But oh, my, I never noticed that 7254 has a "naked" %:

         gsma-urn-char         = ALPHA / DIGIT
                                 / "-" / "." / "_" / "%" / ":"

Someone should have caught that mistake!

> <Roozbeh>: With the previous comment you gave about replacing "%"
> withpct-encoded, then the text is modified to 
>
>    pp2-urn              = "urn:" pp2-NID ":" pp2-NSS
>    pp2-NID              = "3gpp2"   
>    pp2-NSS              = meid-specifier / future-pp2-specifier
>    meid-specifier       = "meid:" meidval   
>    future-pp2-specifier = future-specifier [ ":" 1*( pchar / "/" ) ]
>    future-specifier     = 1*pp2-char
>    pp2-char             = ALPHA / DIGIT / "-" / "." / "_" / pct-encoded
>    ALPHA                = %x41-5A / %x61-7A; A-Z / a-z
>    DIGIT                = %x30-39; 0-9

That looks like a good solution.  (Although I think "ALPHA" and "DIGIT"
are defined in ABNF (RFC 5234 appendix B.1) so you don't have to define
them.  (RFC 7254 does not.))

>>     <future-pp2-specifier> and <pp2-defined-nonempty> can comprise
>>     any  ASCII characters compliant with URN syntax in [RFC5234].
>>
>> This is not correct, as the URN syntax allows any pchar, whereas
>> the pp2-defined-nonempty does not allow the sub-delims "!", "$",
>> "&", "'","(", ")", "*", "+", and ",", which are all valid pchars.
>
> <Roozbeh> Perhaps you have looked at revision 14 of this document. The
> refernce is RFC 8141 in revision 15 of the document, i.e.
>     <future-pp2-specifier> and <pp2-defined-nonempty> can comprise any
>     ASCII characters compliant with URN syntax in [RFC8141].

Rereading what I said previously, it was mistaken in a complicated way:
The ABNF (from your version above) is

    pp2-NSS              = meid-specifier / future-pp2-specifier

    future-pp2-specifier = future-specifier [ ":" 1*( pchar / "/" ) ]
    future-specifier     = 1*pp2-char
    pp2-char             = ALPHA / DIGIT / "-" / "." / "_" / pct-encoded

As a result, <future-pp2-specifier> as a whole can contain "any ASCII
characters compliant with URN syntax".  However, the initial
<future-specifier> portion of <future-pp2-specifier> has a more limited
character set.

However, <pp2-defined-nonempty> (as defined in -14) has the limited
character set of pp2-char.  However, you've removed
<pp2-defined-nonempty> in the above revised ABNF, although it's in the
-15 version.

In regard to the "Rules for Lexical Equivalence", I think your changes
are generally beneficial, but I'd have to see the new version of the
section as a whole to make a useful judgment on it.

However, in regard to

   Any identifier in '3gpp2' NSS can be compared using the normal
   mechanisms for percent-encoded UTF-8 strings, where the UTF-8
   is defined in [RFC3629].

The reference to RFC 3629 isn't very useful, since 3629 only tells how to
represent characters as sequences of octets, i.e., it doesn't describe
the percent-encoding.  A better reference is RFC 3986 ("Uniform Resource
Identifier (URI): Generic Syntax"), which does go into the details of
how a non-ASCII character is represented in a URI as a sequence of
%-encodings.

But I think you want to be more explicit about how the comparison is
done, with something like:

   Two identifiers in '3gpp2' NSSs are equivalent if they represent the
   same string of Unicode characters via the normal mechanism for
   percent-encoded UTF-8 strings [RFC3986].

That avoids the complexities around the various ways that Unicode
strings can be compared for equivalence, by just declaring that NSS
equivalence only comes from being the same string of Unicode characters.

Dale

---

From: R Atarius <[email-masked]>
Date: Sun, 18 Mar 2018 01:26:59 +0000 (UTC)

Hello all,
The new revision (16) is now available.
https://www.ietf.org/id/draft-atarius-dispatch-meid-urn-16.txt

ThanksRoozbeh

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 27 Mar 2018 22:50:24 -0400

> https://www.ietf.org/id/draft-atarius-dispatch-meid-urn-16.txt

The new version looks quite good.  I've a few comments, listed in text
order:

Abstract

   This document defines a Uniform Resource Name (URN) namespace for the
   Third Generation Partnership Project (3GPP2) and a Namespace Specific
   String (NSS) for the Mobile Equipment Identity (MEID).

I may have the terminology wrong, but comparing to the next sentence,
you might want to change "Third Generation Partnership Project (3GPP2)"
to "Third Generation Partnership Project 2 (3GPP2)".

3.  Namespace Registration Template

   Registration organization:

   Name: 3GPP2

You might want to spell this out as "Third Generation Partnership
Project 2 (3GPP2)".

   future-pp2-specifier = future-specifier *( ":" 1*( pchar / "/" ))

This ABNF is correct, but somewhat obscure.  Looking at it quickly, it
appears to specify a sequence of "words" separated by ":", where each
word contains at least one character which is not ":".  But in fact,
<pchar> can be ":", so this has the same effect as

That is, the <future-specifier> (which cannot contain ":") can be followed
by ":" and then by one or more (pchar / "/"), with the latter containing
":" in arbitrary places.

So if the ABNF specifies what you want, you might consider the latter
formulation as being more expressive of your intentions.

   <future-pp2-specifier> can comprise any ASCII characters compliant
   with URN syntax in [RFC8141].

Actually, there are sequences of ASCII characters compliant with URN
syntax in [RFC8141] which cannot be <future-pp2-specifier> -- RFC 8141
prescribes that the NSS is "pchar *(pchar / "/")", but
<future-pp2-specifier> can only start with <pp2-char>, which does not
include "~", <sub-delims>, ":", or "@", which are all included in
<pchar>.

You might want to omit this sentence.  Alternatively, it is true that
the part of <future-pp2-specifier> after ":" can be any NSS string.
Though that part is slightly more general than NSS, since it can start
with "/", and NSS cannot.  But it's not clear to me that anything you
can say along these lines is both completely accurate and easier to
understand than the ABNF.

   Rules for Lexical Equivalence:

   Two 3GPP2 MEID URNs are equivalent if they have the same 'meidval' in
   the same sequential order.  Two future 3GPP2 MEID URNs are equivalent
   if they have the same 'meidval'and 'future-pp2-specifier' in the same
   sequential order.

The second sentence needs to be rewritten, because of course, no URN
contains both <meidval> and <future-pp2-specifier>.  Indeed, it seems
like you can get the effect you want by simply saying:

   Two 3GPP2 MEID URNs are equivalent if they have the same character
   string as <pp2-NSS>.

4.2.3.  Check Digit

   This is a single hexadecimal digit (bits 1-4 of octet 8) and is used
   as assurance of integrity in error-prone operations, e.g. when used
   with certain types of readers during inventory management operations.
   The check digit is not transmitted by the mobile equipment and are
   not used in the MEID URN.

In section 4.2, for completeness, you give a lot of information that is
not strictly required.  However you don't give the really non-trivial
bit of information:  the formula for the check digit.  After reading
this section, I was left curious what the check digit formula actually
is!

Dale