This document was discussed on the urn-nid list between late March and
mid-April 2013.  At the time, Ted Hardie and Patrik Fältström
commented, and the authors addressed some of their comments.  In the
end, I think that not all of their comments were adequately addressed,
so I'm explicitly including Ted and Patrik in the "to" field here, to
bring their attention to the publication request and to my AD review.
Ted, Patrik, please check whether the current version

https://datatracker.ietf.org/doc/draft-spinosa-urn-lex/

...addresses your issues to your satisfaction, and also let me know if
any of my comments below are totally off base.

---
I am very uncomfortable with this document, for a number of reasons:

1. The use of two-character jurisdiction identifiers was brought up by
Ted, and I'm not happy with the resolution, which seems to recommend
massive renaming of existing -- possibly quite old -- documents in
cases where the identifiers change.  This is simply not practical, and
goes against the concept that URNs be persistent.  Obviously, no one
can guarantee permanence, and persistence doesn't mean permanence.
Nevertheless, when we can anticipate issues (and particularly when we
have a demonstration than an issue has occurred, as is the case with
"ai"), we should deal with them in a way that doesn't upset the entire
apple cart.  Ted suggested three-letter jurisdictions, which seems a
reasonable approach.  There might be others.  Massive renaming of
perhaps many thousands of years-old documents isn't a reasonable
approach.

2. The whole "national characters" discussion in 3.4 seems odd.  It
was mentioned in the reviews, and corrections have been made.  I can
live with what's there now, but it still seems wrong to specify things
this way -- see item 3 for more.

3. Section 3.5 is grossly language-dependent, and was so obviously
written by people whose language supports what's demanded there.  As
it happens, turning "Ministry of Finance" into "ministry.finance"
works fine in Italian, as well as in Spanish, French, and English.  We
have words that mean "the" and "of", and such, which we can eliminate.
 Languages such as Russian do not; the noun forms themselves change
with the case, to give the meaning of the word "of" in "of finance" in
the noun itself.  "Ministry of Finance" in Russian is "министерство
финансов" (Ministerstvo Finansov), but the nominative word for
"Finance" would be "финансы" (Finansy).  Should the Section 3.5
process have it normalized to "министерство.финансы", to eliminate the
"of" that's implicit in the case of "финансов"?  Does it matter?  (And
I don't even want to try to think about how this gets done in Chinese
languages.)

All this stuff in Sections 3.4 and 3.5 (and the later sections as
well) would be fine if it were in a non-normative example of how one
jurisdiction has chosen to create the names.  But apart from the
protocol requirements that have to do with required encoding of
non-US-ASCII characters, having this stuff be normative just strikes
me as wrong.  And pointless: does it really matter *how* the names are
assigned?  It should simply be up to the jurisdiction to create the
names, and if my jurisdiction chooses to name its documents as
"urn:lex:barryland:000000000001", then
"urn:lex:barryland:000000000002", and so on... or perhaps I want to
use SHA-1 hashes, as in RFC 6920.  Is that really a problem?

If you really are trying to set up a system wherein the URN can be
computed correctly from the document's title and other metadata, I
submit that such an effort may work for some situations, but is doomed
to fail in general.

4. You appear to be requiring that "urn:lex:" names work as locators
in HTML hrefs.  From Section 1.5:

   LEX names will be used on a large scale in references as a HREF
   attribute value of the hypertext link to the referred document.

...along with the whole "lex.urn.arpa" setup described in Section 6,
and the registration of the NAPTR records.

This is unprecedented, and, again, strikes me as wrong.  URNs can be
mapped into corresponding URLs, and being able to do so is what makes
them useful, but it seems that such mappings will be very much
jurisdiction-dependent, and it seems *very* unlikely that

   <a href="urn:lex:barryland:000000000001">

...could be dereferenced as it stands.  That would require that every
browser (and every other application that processes these things) know
how to dereference every jurisdiction's LEX names -- and you're
depending upon the entire world building their resolution around your
structure and the registry you aim to set up.  Unless I'm seriously
misunderstanding something, this just seems like it won't work.  In
any case, what you're describing in Section 6 is not a URN namespace,
but a URI locator scheme.

---
I have a couple of other comments, at a much lower severity than the others:

- What's with the reference to W3C in the abstract?

- Section 3.9 specifies what to do with ordinal numbers.  Why are
those called out specifically, while cardinal numbers aren't?  Why
should I handle "law relating to a second home" one way (ordinal
number), and "law relating to two homes" (cardinal number) in a
different way?  But, again, this is related to my comment above about
why any of this is normative, and that comment applies to all sections
from 3.4 to 3.9.

There seems to be a lot of stuff in Section 4's subsections that also
specifies how these names should behave in practice, but is doing it
with normative requirements on the contruction of the name itself.  As
with the things in Section 3, these seem nice as explanations of
desirable (even required) characteristics, but wrong as normative
mechanisms with respect to the name structure.

Barry, Applications AD