[urn] Re: GS1 URN: submission

[[e-mail]]

Here are my first-pass comments on the gs1-urn-rfc-v5.6.0.txt:

The Registrant and Contact do not include a phone number or an e-mail
address or even a role name in the postal address.

   Process of identifier resolution:
      Resolution is optional. URN validity is independent of the existence
      of any resolver service. Resolver services provide a convenience
      mechanism for obtaining representations associated with a URN.
      GS1-authorised resolvers may provide authoritative representations.

      Example:

         https://resolver.gs1.org/resolve/[urn]

      where [urn] is the percent-encoded form of the URN.

It's not clear from the text whether these URLs are supported or not.
Since it's labeled "Example", that doesn't matter officially, but it
probably would help the reader to state whether or not this URL does
anything.  Appendix E seems to describe a resolver service.  ISTM that
if you intend a resolver service and have a definition for it now, you
should clearly specify it, and if you do not, you shouldn't mention it.

Also, the URL template shows the URN embedded as part of the path of a
URL.  Since every character allowed in a URN is allowed
"un-percent-encoded" in the path of a URL (see RFCs 8141 and 3986), the
phrase "where [urn] is the percent-encoded form of the URN." is not
needed.

In regard to the relationship between namespaces EPC and GS1:  You
expect there to be some semantic correspondence between the namespaces
but there is no official lexical equivalence between them.  The latter
should be made extremely clear, as otherwise people will mistake it.
There are three places where this relationship matters;

   Rules for lexical equivalence:

This ought to mention that no GS1 URN is lexically equivalent to any EPC
URN.

   3.1. Relationship to RFC 5134
      ...
      Implementations MAY support mappings between EPC URNs and GS1 URNs
      where such mappings are defined by GS1 standards or implementation
      guidance.
      ...
      The existence of such mappings does not imply equivalence between the
      namespaces. Each namespace retains its own syntax, governance model,
      and resolution semantics.

Amplify "does not imply equivalence" to "does not imply lexical
equivalence".

   Appendix G. EPC <-> GS1 Mapping

      This appendix is informative and is provided to illustrate
      interoperability between the namespaces described in Section 3.1. The
      mappings shown herein do not establish semantic equivalence between
      the EPC and GS1 namespaces and do not alter the independent governance
      or syntax rules applicable to either namespace.

Again, I would amplify "do not establish semantic equivalence" to "do
not establish semantic or lexical equivalence".

   4. Security Considerations

   GS1 URNs are opaque identifiers. Security considerations are
   therefore limited to those common to URNs in general and to the
   resolver infrastructure used around them.

GS1 URNs aren't opaque, as they have a lot of internal structure which
is intended to be parseable.  But they are identifiers of things that
cannot be *acted upon* via the URN, so there are no namespace-specific
security considerations.

   Appendix A. ABNF Grammar

      urn                = %s"urn"
      gs1                = %s"gs1"

"%s" has crept into the grammar in a number of places.

      std-branch         = %s"std" ":" std-id [ ":" version ]
                            [ ":" clause ]

      version            = 1*( DIGIT / "." )
      clause             = 1*DIGIT *( "." 1*DIGIT )

This is ambiguous, as <version> and <clause> both contain 1*DIGIT.  E.g.
in

   urn:gs1:std:abcd:1234

"1234" could be either <version> or <clause>.  Unless you make it that
no string could be either a <version> or <clause>, you can't make both
of them independently optional.

   Appendix A.1. Informative Constraints
      ...
      AI 01 - GTIN
         * numeric only
         * exactly 14 digits
         * leading zeroes preserved where required for GTIN-14
           canonical form

Given that the entry states that the value is exactly 14 digits, clearly
leading zeros are required whenever the nonzero digits do not amount to
14 digits.

The table "Illustrative constraints" is not very clear.  I think it
means that it is a table of defined <ai> values and their corresponding
<value>s but it doesn't say that.  Indeed, it's just a guess that "01",
"00", "402", etc. are actually intended as <ai> values.

Very similar (and somewhat clearer) information is presented in Appendix
F, but again it doesn't state explicitly what the entries mean.  ISTM
that these should be made clearer and if possible combined.

Dale