Dear Scott, thanks for your contribution and sorry for not having addressed your previous comment, which we report here below and more below our answer. > The document describes a URN syntax and provides a set of principles relating to > a resolution service for the URNs. > > I do not quite know how to approach this document for an OPD-DIR review since such > reviews primarily focus on any issues that might impact a network operator or the operator > of a service and this document mostly consists of the URN syntax and support for the syntax. > > The document mentions that "the "lex" namespace resolver will be expected to cope with a wide > variety of "dirty" inputs" (section 8.1). The document attempts to describe a design of a "flexible and > robust" resolver but I expect that the foibles of the real world will too frequently cause resolution failures - > I do not have any suggestions to make this less likely although it seems to me that being quite as forgiving > in what the resolver tries to deal with (partial matches, etc.) may not be worth the effort. It seems to > me that the only way for someone to have a LEX URN to resolve is to get it from a publisher (since it will > be essentially impossible for someone to guess one) why is it not reasonable to assume the URN is an > accurate copy of what the user received and simply reject it if it does not parse. (I say that it seems > impossible for someone to guess since the URN hierarchy and components seems so locally defined.) > > So, personally I would recommend removing the fuzzy matching part and thus simplify > operation and reduce operational issues. > The specifications for the fuzzy/partial matching behaviour of a resolver have been introduced to address the specific nature of legal references. In fact, the most part of legal references, by nature, are expressed at Work level only, thus referring to a set of resources; only very rarely they are at _expression_ level; never at Manifestation level. In this sense they are, so to say, partial/incomplete with respect to the full identifier. What is most interesting is in fact to get to the addressed document and then only subsequently to choose, if necessary, between the various versions and/or manifestations (using for example links between different versions of the document such as [RFC8288], see par. C1.1) Moreover, sometimes textual legal citations may lack some elements of identification (or they are implicit), therefore, in these cases, it can be difficult or impossible to automatically generate the complete “lex” identifier associated to a reference, even at the Work level only. For this reason the exact 1-to-1 matching between provided ID and document ID in the resolution is almost without sense in the legal domain. On the other hand, the resolver can be configured to provide, by default, the "best copy” (according to certain rules) of a set of documents (this is actually what the http-based version of the lex identifier is meant to do).
Best regards Pierluigi and Enrico --- Enrico Francesconi IGSG - CNR [ex ITTIG - CNR] Institute of Legal Informatics and Judicial Systems Italian National Research Council Via de' Barucci 20 50127 Florence Italy Tel: +39-055-4399-665 Fax: +39-055-4399-605 email: enrico.francesconi@xxxxxxxxxxx
|
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
