Subject: Re: Publication request for draft-spinosa-urn-lex

From: Enrico Francesconi <[email-masked]>
Date: Fri, 5 Dec 2014 12:49:19 +0100

Dear All,
   hope this email finds you well. This is just to ask you if there are any
news in the revision of urn-lex draft v.09, as well as about our replies to
your remarks.

Best
   Pierluigi and Enrico

2014-10-01 18:03 GMT+02:00 Barry Leiba <[email-masked]>:

> >    after our replies (on July 4th, see below) to Barry's remarks on
> > the current version (v.09) of urn-lex specifications, we are back to
> > ask you if there are any news.
>
> Aiiieeeeeeee!  I'm so sorry that this got lost in my mess.  I'm
> embarrassed.
>
> > Meanwhile, we have produced a new version (v.10) of the urn-lex
> > specifications (in attachment) including most of Barry's suggestions,
> > as revised in our last reply.
>
> I will have a look at that version today, and will reply today or tomorrow.
>
> > We would like to include acknowledgments to all of you having
> > collaborated in commenting and improving the draft, but we
> > actually do not know if this is usual in case of IETF members.
>
> This is entirely up to you.  It is customary for authors to "ack"
> those who they feel have provided important contributions, and that is
> the authors' judgment.  Speaking for myself, I can assure you that I'm
> happy either way, and will certainly take no offense, whatever you
> decide.
>
> Barry
>

-- 
---------------------------------------------------------
Enrico Francesconi
ITTIG - CNR
Institute of Legal Information Theory and Techniques
Italian National Research Council

Via de' Barucci 20
50127 Florence
Italy

Tel: +39 055 4399665
Fax: +39 055 4399605
email: [email-masked]
---------------------------------------------------------

---

From: Barry Leiba <[email-masked]>
Date: Tue, 9 Dec 2014 15:03:10 -0500

> news in the revision of urn-lex draft v.09, as well as about our replies to

And after my first message about how embarrassed I was at letting this
drop, I have nowhere else to hide now.  Please accept my apology for
this.

I have a flight on Thursday, so if I can't get to this on Wednesday I
will do it on the flight.  Please help me: If you don't hear something
from me by the end of your work day on Friday, please send me another
reminder.  I intend to handle this right away, so you have my
encouragement to annoy me as much as necessary until I do it -- and we
can both hope that little or no annoyance is actually needed.

Barry

---

From: Enrico Francesconi <[email-masked]>
Date: Tue, 9 Dec 2014 23:29:12 +0100

Dear Barry,
   thanks for your reply. Please do not worry about this, we understand that the revision process may take long, as actually did took the drafting of the urn-lex specifications.
Nevertheless we are eager to know your opinion!

Best 
   Pierluigi and Enrico

Via de' Barucci 20
50127 Florence
Italy

Tel: +39-055-4399-665
Fax: +39-055-4399-605

---

From: Barry Leiba <[email-masked]>
Date: Sun, 14 Dec 2014 14:53:17 -0500

OK, I've looked again at your responses to my review, and at the
changes you've made.  I see that you've made some of the minor changes
I suggested, but that you're holding firm on some of the major points,
which you haven't made changes for.  I'll come back to the two of
those that I think are most important:

* You very much want to mandate a mapping between the title of the
document and the URN.  I think this is very much ill-advised.  You
think this provides discoverability, in that someone can look at a
document title and determine the URN without having to look it up.  I
think this will fail miserably in practice, because there are too many
variables and there will be no way to get it right, in general.
Surely it will work sometimes, but it will fail to work often enough
that people will have to use searches to find the URN anyway, and the
mandated mapping will simple run counter to the filing systems that
some jurisdictions will need to use.

So I stand by my suggestion that you make that a suggested mechanism,
and soften the language that mandates it as the only way.

* There's a bunch of other stuff that I suggested that you soften the
language about, making it clear that it's stuff you have found useful,
without making it a mandatory part of how the URNs are done.  Again,
you think it's important to keep it as it is, and I think that's very
much ill-advised.

I don't see how this scheme can be generally useful as a worldwide
"lex" URN namespace with the kinds of mandatory handling you specify
in this document.

If you absolutely insist on leaving it as it is, I will go ahead and
ask someone to be a document shepherd so we can process this document
and its registration... and the document shepherd will weigh in with
his opinion (which I will not influence), so you'll get another view
on this.  After that it would go out for last call to get the IETF's
and the IESG's view, and see where we are.

I'll stress that I think it's valuable to register this and have the
details recorded, so I *want* this to go forward.  I'd just rather see
it go forward in a form that's flexible enough to actually be useful
internationally, while still representing your model for how you'd
like the URNs to be formed.  My view is that if you put it that way,
then anyone who wants to play your way can do so... and that it's best
not to *require* that in order for "urn:lex:" URNs to confirm to this
spec.

Let me know whether you'd like to continue discussing this, or whether
you'd like me to find a shepherd now, and get a new opinion on it.

Barry

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 15 Dec 2014 14:11:29 -0500

There are at least some technical questions that need to be addressed.

1) The ABNF in appendix A contains <national-name>, but it seems to be
intended to be what is described as <local-name> in section 4.3.

2) The use of % for escaping is incompatible with the generic syntax of
URNs:

      encoded   = "%" (1*6DIGIT / ("x" 1*6HEXDIG))  
                                 ; Hexadecimal digits (0-9, A-F)

as opposed to:

   pct-encoded   = "%" HEXDIG HEXDIG

3) The syntax for using % does not allow an encoded string to be parsed
unambiguously:

   jurisdiction-unit = alfanum *normal

   normal = alfanum / "."

      alfanum   = lowercase / DIGIT / encoded

      lowercase = %x61-7A        ; lower-case ASCII letters (a-z)
                                 ; DIGIT %x30-39 decimal digits (0-9)

      encoded   = "%" (1*6DIGIT / ("x" 1*6HEXDIG))  
                                 ; Hexadecimal digits (0-9, A-F)

For example, considering the string "x%1234" as a <jurisdiction-unit>,
it could be one <lowercase> followed by a <DIGIT> and three <encoded>s
("x", "%1", "2", "3", "4") or one <lowercase> followed by one <encoded>
("x", "%1234").

Perhaps this does not matter if it is not required that the underlying
UTF-8 string can be derived from the URN, but if so, then there is no
assurrance that two distinct UTF-8 string will be encoded as distinct
URN substrings.

Dale