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

[Enrico Francesconi <[e-mail]>]

Dear All,
   first of all sorry for being late with our feedback but this is a very busy period which, joint with vacations, did not allow us to meet and work on LEX specifications as often as we would have liked.
Therefore, let us reply on the first part of your comments (points 1, 2, 3), then we will be back to you with the second part soon.

So please find in-line a point-by-point reply on them.


On 05/mag/2014, at 16:37, Barry Leiba <[e-mail]> wrote:

> This is a follow-up to my review far below, giving some concrete suggestions.
> 
> I'm looking at what I consider to be the major issues with the LEX NID
> proposal, and I'd like to put forth my own proposal for how to resolve
> them and move forward.  I'm not saying that this is the only way
> forward, but I am saying that these are issues that need to be dealt
> with, and that what I'm proposing will deal with them to my own
> satisfaction.  Please consider adopting these into the draft and
> posting an update.  And please feel free to discuss any of this with
> me.
> 
> The major issues I see are these:
> 
> 1. While the two-character jurisdiction IDs are not likely to change,
> they might do so, and have done so already.  The desire for URN
> persistence makes it extremely unwise to expect wholesale renaming,
> should some IDs change in the future.  Ted has suggested using
> three-character jurisdiction IDs to avoid this problem, and I urge you
> to switch to that mechanism.

The choice of using two characters still seems to us the most suitable solution, since it is the most used way to identify countries (in the DNS it is the ccTLD) and related resources, while it is well known that a three-letter code is not so common as two-letter one.
If we move to a three-letter code for jurisdiction identification (that definitely reduces the probability of re-assignment) nevertheless we are not guaranteed that a re-assignement might occur, as already happened in the past with re-assignment of ROU code from Uruguay to Romania, for example. Moreover the AFI code (for French Afar and Issas), with other 23 ones, has been deleted from ISO 3166-1.
We consider that the problem of the renaming legal resources already identified, as a consequence of a country code re-assignment, is similar to the one that might occur for other network resources (as the change of hosts fqDN).
For example if "http://www.gov.ai" is used to identify the website of the French Afar and Issas government before country code re-assignment, such host must change its fqDN after the code re-assignment in order that it is visible, otherwise we are going to point to a website of the Anguilla government.
Therefore, in light of these considerations, the most suitable solution for dealing with resource names with country-code re-assignment seem to us the following proposal, which revises the one suggested in urn:lex v.09 . In particular:
- changing the old country code with the new code assigned to the same country/jurisdiction (ex: "ai" into "dj" (Djibouti)) (recommended solution);
- changing the old 2-letters country code with a code under the virtual domain "lex" (as suggested in Section 2.4 for organizations without a registered domain). In our case “ai.lex” or “ai-1974-1983.lex”.. In this case French Afar and Issas will open a new entry (e.g. ai.lex) in the lex.urn.arpa zone of the DNS under which including the proper NAPTR record.
We have also considered the possibility not to change the country code but this solution would need a software able to route the resolution chain of the documents issued before a certain date (the one of re-assignment) towards a proper resolution service. In the case under consideration, Anguilla, under a proper agreement between the parties, should implement a software able to route to French Afar and Issas the resolution of the documents before the date of reassignment.


> 
> 2. You're requiring that LEX URNs conform to some naming convention
> that appears to be built around the documents' titles.  That
> requirement is very much dependent upon languages and character sets,
> and isn't advisable on that ground; it's also likely to run counter to
> the desire by some jurisdictions to use catalogue numbers and other
> schemes that have nothing to do with document titles or keywords.

Actually in the urn:lex naming convention we rely on resource details (or metadata terms: for example the issuing authority, the type of act, etc.); we use documents' titles as optional specifications only, able to facilitate the identification of the resources (for example accounting regulation).
Moreover in relation to point 2 and 3 of Barry's email dated Apr 29th, we would like to underline that the whole URN:LEX approach aims to create transparent, self-explanatory names, in order to promote the interoperability of the resources, so that given an act it is possible to construct its URN:LEX identifier on the basis of its details (metadata). Such construction is bi-directional, from the urn to the act and from the act to the urn.
This facilitates the development of parsers able to construct the URN:LEX ID of the referenced act (textual citation actually includes the act details). The rules given to create such names aim to facilitate the construction of unequivocal names. The elimination of stop words (like replacement of spaces, connectives and punctuation marks) aims to reduce possible errors due to incomplete citations.
In case such connectives do not exist, but are implicit in a specific name (like in the cited Russian genitive example (Ministerstvo Finansov)), no stopword elimination will be accomplished and no case transformation will be made (from genitive to nominative case). Therefore the name of the authority in the Russian case will be: ministerstvo.finansov, as it appears in the heading of the act. Such behaviour will be the same in languages having declensions or in agglutinating languages.
As for opaque names (as "urn:lex:barryland:000000000001”) it is definitely possible that a jurisdiction decides to use opaque names, like registry codes, but such identifiers loose interoperability not only between jurisdictions but mainly within a single jurisdiction. In fact, to create a link via urn to a target act, the user has to discover the number with which the act has been registered (note that only the referred act details are easily known from the textual citation, while not the opaque code). For example, from a citation of a French law like “loi n. 106 du 15 mars 2004", the URN:LEX of the target document can be easily built as "urn:lex:fr:etat:loi:2004-03-15;106" while the registry code of it has to be discovered by an additional search.

Moreover, managing a centralized registry for assigning a unique code to every act at national, regional and local levels, may create serious problems within each jurisdiction. The structure of the URN:LEX identifier, on the other hand, is aligned to the typical federative approach on the Internet, which is organized according to delegation chains, allowing each authority to create its own numbering system, and to implement its own resolver.


> 3. You're setting up direct dereferencing of LEX URNs as though they
> were HTTP URIs, and that's contrary to how URNs are used and puts a
> burden on client software to know how to do the dereferencing.  It
> also seems unnecessary in general: if this NID catches on, documents
> and their URNs will be indexed and will be locatable through search
> engines.  Further, organizations that makes legal documents available
> are likely to provide their own repositories for the documents, and,
> hence, their own mappings, which might lead one to a copy that has
> notes and commentary alongside it, for example.  A better approach is
> to suggest a way of mapping URNs to HTTP URIs, and to offer a service
> and registration that jurisdictions could opt into.


The URN-LEX dereferencing is aligned, in our opinion, to RFC 3405; it permits the implementation of both:
- the discovery of the resources
- the use of the urn of the target document in document hyperlinking

The resolution service with the discovery of the resource can be based on a series of components which are:
a) plugin for browsers able to handle a “urn:” schema (a prototype is available);
b) a DDDS service, implemented on a server (a prototype is available);
c) DNS chain with the related NAPTR records (a prototype is available);
d) a resolver for a given subset of documents 


A more simplified approach (known as “trivial convention for using HTTP in URN resolution” according to RFC 2169) can be actually using the URN of a target document in document hyperlinking. It is implemented by sending an HTTP request including the address of the resolver and the URN of the target document

http://<resolver>/uri-res/N2L?urn:lex:..

In both the previous cases, a 1-to-N association between a resource identifier and different manifestations of such resource can be obtained.
On the other hand, as regards mapping between URN:LEX and HTTP LEX, we have actually provided such an approach in Attachment D of the LEX draft specifications (v.09). In that paragraph we have underlined the main difference between URN and HTTP-based URIs related to the concept of dereferentiability. As written in Attachment D, the dereferentiability property is available for http-based identifiers either with or without a resolver allowing a 1-to-1 association with the "best copy” of the resource; in the legal domain it is related to the unique act manifestation of a specific publisher and format. The same property holds for URN identifiers, as long as a resolver is properly set-up, allowing 1-to-N association with more manifestations of a resource (act).

The behavior of a URN:LEX resolver, which can be invoked in document hyperlinking as http service, responds to the need of having the possibility to retrieve more manifestations of an act (ex: with or without notes, in pdf or in html, etc.), using the URN of the act itself.




We would be pleased if you can comment on our reply. Meanwhile we will work on the second part of your comments and be back to you soon.

Again, many thanks for your interest in our proposal
best regards

   Pierluigi and Enrico


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

Via de' Barucci 20
50127 Florence
Italy

Tel: [phone]
Fax: [phone]
email: [e-mail]
---------------------------------------------------------



> 
> What I'm suggesting here pulls out the actual normative requirements
> for LEX URNs, and leaves the other things as suggestions for
> implementation and deployment, making clear what behaviour is desired
> without requiring things to be done a certain way.
> 
> I'll note that if your advice and suggestions are good, they'll likely
> be widely adopted even if they're not put forth as requirements... but
> that LEX URNs can still be useful even for jurisdictions that choose
> not to use that advice.  So I think moving to this setup not only
> resolves the specification issues, but also results in a more flexible
> NID.
> 
> -- Section 1.1 --
> 
> OLD
>   The identifier is conceived so that its construction depends only on
>   the characteristics of the document itself and is, therefore,
>   independent from the document's on-line availability, its physical
>   location, and access mode.
> NEW
>   The identifier itself is assigned by the jurisdiction that owns the
>   identified document, and it is independent from the document's on-line
>   availability, its physical location, and its access mode.  Even a
>   document that is not available online at all may still have a LEX URN
>   that identifies it.
> END
> 
> OLD
>   In an on-line environment with resources distributed among
>   different Web publishers, uniform resource names allow simplified
>   global interconnection of legal documents by means of automated
>   hypertext linking.
> NEW
>   In an on-line environment with resources distributed among
>   different Web publishers, uniform resource names allow simplified
>   global interconnection of legal documents by means of automated
>   hypertext linking.  LEX URNs are therefore particularly useful
>   when they can be mapped into locators such as HTTP URIs.
> END
> 
> -- Section 1.2 --
> 
> It's nice to have this list for now, but the hope, of course, is that
> many entities will pick this up, and that this list will become
> obsolete very quickly.  Maybe the answer here is to just say, "The
> following entities support this proposal at the time of publication:"
> (which kind of seems self-evident, but which clarifies that this isn't
> just for a few organizations only).
> 
> -- Section 1.3 --
> 
> OLD
>   The LEX naming convention has interpreted all these recommendations,
>   proposing an original solution for sources of law identification.
> NEW
>   Section (??) supplements the required name syntax with a suggested
>   naming convention that has interprets all these recommendations
>   into an original solution for sources of law identification.
> END
> 
> -- Sections 1.4 thru 1.6 --
> 
> These sections should be reworked so that they clearly specify
> desirable characteristics, but not normative requirements.  Some of
> the content is likely to be better moved to a later section.
> 
> -- Section 2.3 --
> 
> There's a good reference for ABNF: RFC 5234.  You should use it (as a
> normative reference), and not repeat syntax definitions here.
> 
> -- Section 3.3 --
> 
> Yeh, one has to love how legal folks talk.  But, really, this should
> be much, much simpler and more straightforward: 'Names belonging to
> the "lex" namespace are case-insensitive.  They MUST be created in
> lower case, but names that differ only in case MUST be considered to
> be equivalent."
> 
> (If you then feel that you have to explain why, go ahead and do it in
> another paragraph.)
> 
> -- Sections 3.4 thru 3.9 --
> 
> These need to be moved into the suggested implementation section.
> 
> -- Section 4 and its subsections --
> 
> This is the suggested implementation section.  The top-level text in
> Section 4 should make it clear that none of this is required for
> constructing the URN, but is advice for making the URNs more useful.
> (Personally, I'm not convinced that it does make them more useful, but
> if you're convinced of it I have no objection to your saying so.)
> 
> -- Section 5.1 --
> 
> This needs to be fixed to address the "jurisdiction IDs shouldn't
> change" problem.
> 
> I'll note that even three-character IDs might change, in the event
> that a country name changes, but the former three-character ID is not
> likely to be reassigned.  If we want to be *really* robust about it,
> we could create a registry of codes that are never changed or reused,
> where the registry maps those codes into the jurisdictions as we know
> them.
> 
> But that's probably more than we need here.
> 
> -- Section 6 and its subsections --
> 
> I very strongly advise pulling back on this and working out some text
> along these lines:
> 
> - As with other URNs, LEX URNs can not be directly used as "clickable
> links" -- they can't be directly dereferenced.
> 
> - Nevertheless, they are most useful when document can actually be
> located by using them.
> 
> - That means that we expect search engines to use them as keys for
> locating documents.
> 
> - Owners of document repositories should provide easy mapping from
> URNs to the locators for the documents in their repositories.
> 
> - ITTIG-CNR will maintain a mapping service that will be made
> available to jurisdictions that choose to use it.  The service will
> locate documents through URIs of this form:
> 
>   http[s]://lex.ittig-cnr.gov.it/urn/lex/<jurisdiction>/<local-name>
> 
> (with characters suitably encoded, if necessary, of course).
> 
> - Documents within the "it" jurisdiction will be directly served by
> such URIs.  That is, "lex.ittig-cnr.gov.it/urn/lex" is the mapping
> prefix for the "it" jurisdiction.
> 
> - Other jurisdictions may register their own mapping prefixes with
> ITTIG-CNR.  ITTIG-CNR will redirect accordingly.  For example, if "br"
> registers a mapping prefix of "lex.senado.gov.br/lex-map", then the
> URN
> 
>   urn:lex:br:2013-003401-00003
> 
> ...could be converted to the URI
> 
>   https://lex.ittig-cnr.gov.it/urn/lex/br/2013-003401-00003
> 
> ...which would then be redirected to
> 
>   https://lex.senado.gov.br/lex-map/br/2013-003401-00003
> 
> - Naturally, each jurisdiction's mapping prefix could be used
> directly, as well.  It's just that ITTIG-CNR is nicely providing a
> referral service.
> 
> Now, it's possible that ITTIG-CNR doesn't want to provide the referral
> service, and you might just want to set up the registry; that's fine
> as well.  And it would be reasonable to have it be an IANA registry,
> rather than something maintained by ITTIG-CNR.  I suggest a
> registration policy of "First Come First Served" (with a reference to
> RFC 5226), but you might want to use "Expert Review", with explicit
> instructions that the designated expert is *only* meant to check that
> people are not registering for jurisdictions they have no connection
> to (malicious or accidental).
> 
> -- Section 7.6 --
> 
> The IANA Considerations would now replace the urn.arpa stuff with the
> setup of the registry that I'm proposing above.
> 
> -- Section 7.7 --
> 
> OLD
>   This document introduces no additional security considerations beyond
>   those associated with the use and resolution of URNs in general.
> END
> 
> This is patently false.  The system you're proposing has some huge
> exposures to name collisions, faulty dereferencing and resolution, and
> so on.  The changes I'm proposing here make it somewhat better, but
> you still need to talk about issues involved with name
> creation/mapping/resolution for cases where your suggested mechanisms
> are used.
> 
> I can guarantee that Stephen Farrell will shred your document when it
> comes to the IESG if you don't flesh out the Security Considerations
> and actually think about how what your proposing can accidentally go
> astray... or can be misused, manipulated, or attacked to go astray.
> 
> -- Appendices --
> 
> Finally, I'm not sure what might have to be reworked in the appendices
> to go along with the other changes... but it's likely that some
> changes will be needed.
> 
> -----------
> 
> OK, so... I know this is a lot.  I think it's conceptually *not* a
> lot, and is conceptually quite contained.  But it's a massive
> reorganization and rethinking of the document.  As I said, please
> consider this and please discuss it with me.  I think it's important
> to get the "lex" NID assigned and registered, and I want to help you
> get that done (and I know that this has dragged on for a long time).
> Please work with me on this, and let's get something that works for
> you and that the IETF regulars who have a specific URN architecture in
> mind can also accept.
> 
> Barry, Applications AD
> 
> 
> On Tue, Apr 29, 2014 at 9:06 PM, Barry Leiba <[e-mail]> wrote:
>> 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