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

[Enrico Francesconi <[e-mail]>]

Dear All,
   as promised, please find here below the whole set of our point-by-point replies to your remarks. For the sake of completeness we include also the first part of our replies already posted in a previous email (sent on June 13th).

Please consider that a new version of the urn:lex will be drafted after the conclusion of this comments exchange.

Thanks again for your collaboration, 
hope to hearing from you soon
best regards

   Pierluigi and Enrico


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/N2Ls?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.


>
> 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

We would propose the following version of this paragraph:

“The identifier is conceived so that its recommended construction depends only on
the characteristics (details) of the document itself and is, therefore,
independent from the document's on-line availability, its physical
location, and access mode. The identifier itself is assigned by the jurisdiction that owns the identified document. Even a document that is not available online at all may still have a URN LEX that identifies it.”


> 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

We propose this version:

“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 or associated with locators such as HTTP URIs.”

>
> -- 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).
>

We agree with this proposal

> -- 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

We agree with this change. Maybe instead of “Section (??)” we can write “This document ”

>
> -- 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.
These 3 paragraphs have been placed in this position so to give an overview of the aims and possibilities of the LEX specifications and the way how to use it in association to a legal document or a legal information management system. This general information is shown before giving the details of the standard. In case needed some content from sections 1.5 and 1.6 can be moved later, maybe after such details, anyway any other suggestions are welcome.

>
> -- 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.
>

Ok

> -- 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.)

Ok

>
> -- Sections 3.4 thru 3.9 --
>
> These need to be moved into the suggested implementation section.

We would proposed the following re-naming of Section 3:

3. General Syntax and implementation features of the LEX Identifier

>
> -- 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.)
>

The whole set of urn:lex specifications are conceived with the aim of promoting interoperability between legal information systems within a jurisdiction but also between different jurisdictions. That's why urn:lex IDs are expected to be self-explanatory, capable of being deduced from documents formal details, always reported in document headers or in the document citations.
For example, giving the following citation:

loi n. 106 du 15 mars 2004 previously taken as example

you can describe such reference with the urn:lex of (and create the related hyperlink to) the target document by the formal details contained in the citation itself, as follows:

urn:lex:fr:etat:loi:2004-03-15;106

without having a previous access to the target document.

Using opaque IDs this cannot be possible anymore.
For example if the previous target document is identified by:

urn:lex:fr:000000000001 or whatsoever opaque ID

the possibility of creating the hyperlink from the citation is not possible anymore, unless you previously had access to the target document and you have read the related urn:lex

Please consider that also similar initiatives in the legal domain at EU level (as CELEX number, ECLI, ELI), follow the same approach.

Having said that, it is definitely possible to relax mandatory specifications, for example we can avoid the use of MUST, using instead simply the “indicative”.

ex:
Section 4.3
The <local-name> within the "lex" namespace MUST contain all the
necessary pieces of information enabling the unequivocal
identification of a legal document.

–->
The <local-name> within the "lex" namespace contains all the
necessary pieces of information enabling the unequivocal
identification of a legal document.


However this may produce the lack of one of the main features (transparency and, thereore, interoperability) of the urn:lex scheme.

> -- 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.

On the use of two or three-character codes we have previously replied.
As regards the creation of a registry of codes that are never changed or reused, this seems actually probably more than we need here, considering that ISO codes exist and are widely used.

>
> -- 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).

The resolution service you propose is definitely effective, but provides a 1-to-1 resolution process (1 identifier (urn or http-based) to 1 resource).

The resolution service we propose is aligned with RFC 3405 and provides a 1-to-n resolution process (1 identifier (urn) to n resources)). For example the same act (at work/expression level) can be published with different characteristics (with or without notes, different digital formats, etc.) by different institutional or private publishers. With a 1-to-n resolution process the user may choose the copy (manifestation) he likes most.

If a 1-to-1 resolution service would be sufficient, the adoption of a urn standard would be redundant and an http-based system identifiers could be used.



>
> -- Section 7.6 --
>
> The IANA Considerations would now replace the urn.arpa stuff with the
> setup of the registry that I'm proposing above.

See the above reply.

>
> -- 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.

The sections “Security Considerations” and “IANA Considerations” are aligned with the corresponding sections of other URN NIDs specifications like RFC4854, RFC4729, RFC4688, etc.
The only difference is that the current version of URN:LEX calls for the namespace registration after the specifications approval, while the previous RFCs include a sentence like: “the requested NID has been entered into the IANA registry for URN NIDs”.

The urn:lex approach is based on the same federative philosophy which the DNS is based on: security, as well as names creation, mapping and resolution, are based on a delegation chain described in Section 6.1.

Actually the adhesion to the urn:lex system is on a voluntary basis: whoever wishes to adhere to this naming convention guarantees, within a chain of delegations (see Section 6.1) and within a specific domain, that names would not collide, that a proper resolution system is set up and, as a consequence, that names are properly dereferenced (see also Sections 5.3 and 5.4).
To the best of our knowledge this behaviour is aligned with the behaviour of other URN naming conventions and systems: the whole mechanism is based on hierarchies and delegation chains; every branch of a hierarchy is responsible for the names and the services actually offered, as well as the DNS uses to work.


>
> -- 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



---------------------------------------------------------
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]
---------------------------------------------------------