From juha.hakala@helsinki.fi Fri Jul 5 05:53:13 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FED11E82CB for ; Fri, 5 Jul 2013 05:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.509 X-Spam-Level: X-Spam-Status: No, score=-4.509 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjCeyh23wZaO for ; Fri, 5 Jul 2013 05:53:09 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8D98F11E82C2 for ; Fri, 5 Jul 2013 05:53:06 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r65Cr4mq001362 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Fri, 5 Jul 2013 15:53:05 +0300 Message-ID: <51D6C1B0.7010004@helsinki.fi> Date: Fri, 05 Jul 2013 15:53:04 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: urn@ietf.org References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <4A9225387F6E4CCB5BB1A018@JcK-HP8200.jck.com> <51BC8D66.9050000@network-heretics.com> <7ED5CCF8F4C22A4918928866@JcK-HP8200.jck.com> In-Reply-To: <7ED5CCF8F4C22A4918928866@JcK-HP8200.jck.com> Content-Type: multipart/alternative; boundary="------------080608000406000700010603" Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 12:53:13 -0000 This is a multi-part message in MIME format. --------------080608000406000700010603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, Several comments below. On 16.6.2013 19:25, John C Klensin wrote: > [snip] While I dislike several things about > 3986, I don't see it as nearly as URN-hostile or, for that > matter, different from its predecessors, as you obviously do. Based on RFC 3986, it is possible to say things like this (quote from http://en.wikipedia.org/wiki/Uniform_resource_name): > Since RFC > 3986^ > in 2005, the use of the term [URN] has been deprecated in favor of the > less-restrictive "URI", a view proposed by a joint working group > between the W3C and IETF. > ^ > Both URNs (names) and > URLs (locators) > are URIs, and a particular URI may be a name and a locator at the same > time. Confusing URNs (identifiers) and URLs (locations) like this and introducing URIs has not been helpful. There are people whose requirements for persistence can be fulfilled by URLs, but organizations such as national archives, national libraries etc. which must preserve digital contents for centuries cannot trust on anything that is as technology dependent as URLs. For us, there is a fundamental difference between locators and persistent identifiers. > Nonetheless, I think that getting this right first and then > seeing what, if necessary has to be done to align things with > 3968 (or vice versa) is a reasonable strategy. Agreed. > > That said, I think we need a 2174bis draft to use as the basis > for discussion. Both in the the absence of a posted alternative > and because I belief that most of what is needed is there, I > would prefer to treat draft-ietf-urnbis-rfc2141bis-urn as that > draft. Yes, but the latest draft written by Alfred Hoenes does say a lot about fragment and query which can / should be re-used in the next version of rfc2141bis. It is important to find a compromise which is acceptable both for IETF (from RFC 3986 point of view) and for communities who are using bibliographic and other identifiers and wish to make them actionable in the Internet. If this WG does not find a solution, then groups using persistent identifiers (Handles, DOIs, URNs and ARKs) will develop their own solutions. This is already happening, and some of the solutions I've seen are completely incompatible with the URI syntax. And even if the requirements of RFC 3986 are followed, interoperability may be in danger. >> ... >> Yes, I have a similar interpretation, and agree that RESERVED >> does not imply "prohibited for all time". But of course the >> reason they were RESERVED is that we didn't know at the time >> how to make them work and retain the persistence properties of >> URNs. It's not yet clear to me that we know how to do that >> now, but at least I think I personally understand the issues >> better than I did then. URNs have been in use for more than a decade, which will help us this time. And there is also an emerging technical infrastructure for administering and preserving digital content for long term. Persistent identifiers have to fit into this infrastructure, and so that it will be easy to accommodate new functionality when it appears. This means, for instance, that specifying new resolution services and service related parameters is a simple and fast process. >> And yet, people are accustomed to being able to compose URIs >> out of base URIs and fragment IDs without having to worry >> about whether the result will be valid. They don't know that >> it's stupid to do that, and nothing that 2141bis says is >> likely to affect the vast majority of users that are currently >> accustomed to appending fragment IDs to URIs. It is not stupid to add a fragment if one can safely assume that the identified resource will not change. With URLs there is absolutely no guarantee of that. Within the URN system, there are namespaces such as URN:ISBN where fragments will work as long as the user has a tool with which the resource can be used. > > So, ignoring 3986 and reprising somewhat, I am suggesting that > we > > (1) Allow fragment identifiers for URNs with the "#" delimiter > (because switching delimiters to clearly denote these as > "something else from what one might infer from 3986" would cause > far more problems and incompatibility. OK. But for practical reasons we should make clear that fragment is not part of the NSS and therefore does not identify anything. The fragment indicates just a location within the identified resource and is used by viewing applications once the entire resource has been retrieved. > > (2) Without restricting syntax, make the presence or absence of > fragment identifiers a namespace issue (not a parsing one). Many namespaces would not be able to use the URI fragment as a part of the NSS, because the identifier system prevents such extensions. If fragment is something that is added to the NSS when needed, this problem disappears. Analyzing semantic equivalence of two URNs is also a lot easier if the fragment can be ignored. Generally, URI fragment can be applied in those URN namespaces in which the resolution produces something that has fragments in the URI syntax sense of the word. Specifying in advance which namespaces can use it and which ones cannot may not easy. Manifestation driven namespaces such as ISBN an easy; if I have for instance urn:isbn: for an XML version of the book, it should be possible to use urn:isbn:#chapter2 to indicate the beginning of Chapter 2. There are many identifiers / namespaces which do not cover digital resources themselves. But it may still be possible to use fragments. For instance, ISTC (International Standard Text Code) identifies textual works but not their manifestations. Resolving urn:istc: will by default produce work level metadata. This URN: urn:istc:#author would still identify the entire metadata record, but the user should first see the author element within the metadata record. As an aside, urn:istc:#author is not the persistent identifier of the author; that would be urn:isni:. > 2141-compliant UNR processors, and processors associated with > older namespaces, will presumably get some flavor of "syntax > error - reserved character" errors or some other failure > condition. I don't see that as a problem. If fragments are not part of the NSS, resolvers should just ignore them. And if my memory serves me right, web browsers should not even pass them on along the rest of the URI. > > (3) _Require_ that processors for namespaces that do not allow > fragment identifiers respond to their presence with an error > condition, whether that is a slightly-bogus "syntax error" or > "character/fragments not allowed" report (for backward > compatibility) or some flavor of "not allowed" or "not found". I used to think that there are namespaces in which URI fragment can never be used. But this may not be the case since the fragment applicability depends on resolution services available. We cannot say that using fragment is a priori impossible for e.g. work identifiers such as ISTC. But there will be situations when it is impossible to add a fragment since the retrieved resource does not support fragment usage. > > (4) _Require_ that processors for namespaces that perform > dereferencing that do allow fragment identifiers (note that, if > 2141 were followed, all of these would be new or revised) reject > the things if they don't match identified fragment elements in > the relevant resource. I expect this requirement will be > ignored in namespaces that are already using fragments, but at > least we will have a clear line about compliance. OK. > > (5) As discussed earlier, warn about some types of fragment > identifiers are inconsistent with persistence and prohibit them > in URNs for that reason. I expect this may be ignored as well, > but it will give us a fairly clear line about compliance and at > least won't make anything worse or make the IETF look stupid. It will be difficult to enforce this if the users utilize fragments after the URNs have been assigned. We cannot assume that they are familiar with persistence limitations. If anything, they will feel more comfortable using fragments with URNs than with URLs. > > (6) Make sure that, from a syntax standpoint, fragment > identifiers are clearly part of the URN and including in the > matching rules. None of > > URN:feline:...lion > URN:feline:...lion#African > URN:feline:...lion#Asian > > Match any of the others. This is not how libraries, archives and museums intend to use fragments. Our aim is to allow the users to do things like this urn:isbn: (assigned by the publisher or the ISBN center) urn:isbn:#chapter10 (assigned by a user A) urn:isbn:#chapter 27 (assigned by a user B) and so on. All of these URNs identify the same book and they are semantically equivalent since fragment is not part of the NSS. As regards the example above, Library of Congress subject headings has 68 hits with "lions" (see http://id.loc.gov/search/?q=lions&q=cs%3Ahttp%3A%2F%2Fid.loc.gov%2Fauthorities%2Fsubjects) including e.g. Lion -- Behavior -- South Africa, but all these have their own identifiers. Fragments are not and will never be used to specify different kind of lions in LCSH. > I am agnostic about whether different media types that are used within > (or dereferenced from) the same namespace should be able to impose > their own restrictions on fragments as long as they don't broaden the > rules above. Clearly exactly what is permitted to be useful in a > fragment (uing the book example again, consider "#Chapter3" versus > "Chapter-III") is resource-dependent, not media type dependent. I'd > prefer to avoid the complexity of an additional layer of rules so will > ask for use cases, but I ultimately don't care very much. Yes, the precise form of the fragment depends on the encoding of the identified resource. >> ... >> In my mind at least, a URN shouldn't be associated with a >> document or resource, but rather with a resource definition >> that explains exactly what is being named, and that resource >> definition is part of what you should get back when you >> resolve the URN... so that the client has a better idea of how >> specific that particular URN is (e.g. is it a particular >> document or a particular version of a document or a particular >> rendering of a particular version of a document, or something >> narrower or broader?) It would be useful if IETF folks had a good understanding of how libraries etc. will deal with the challenge of long term preservation and what role persistent identifiers will have in that. If identifier assignment is a managed process (as it should be), different identifiers (URN namespaces) will be used for different purposes. Assuming that the resource is Hamlet, ISTC will be assigned for the work. Resolving the urn:istc will provide metadata record, including URNs of related works (like Hamlet movies), the play's different expressions (translations, illustrated versions, cartoons,...), URNs & URLs of resources about Hamlet, and so on. After selecting e.g. a specific German translation, the user will see its many manifestations. Eventually he may choose one of them, such as freely available PDF version which looks like a printed book, or EPUB 3 version which adapts itself to the tablet the reader is using. So there will be URNs which are associated with the resource, but there will also be many other kinds of URNs, and linking all of them together should help us to provide all users what they want, now and in the (very) distant future. >> >> But in practice we tend to talk about URNs being persistent >> across changes in the document when we actually mean something >> more subtle than that, much as we talk about URNs being >> persistent when we're really referring to a property of the >> binding between the URN and the resource [definition]. Agreed. From library point of view, work identifiers are persistent since works themselves are immaterial and will never change (as a result of changes in e.g. the file format of the resource). Persistence across changes in the document (for instance, as a result of migrating the resource in a new file format) is achieved via mapping the two manifestations and their URNs to one another directly and via the work level record. > > In principle, any URN can refer to any kind of resource. If > there are particular namespaces that constrain themselves as > to only assign URNs to specific kinds of resources that have > specific persistence properties, that's their business, but we > shouldn't define general URN behavior in the presence of > fragment IDs and/or query strings in such a way that it only > works for those corner cases. Most well managed URN namespaces are constrained one way or another. I would not call them corner cases but use cases. For me, totally uncontrolled namespace like UUID is a corner case since most resource which have urn:uuid will not be preserved for future generations. URN should take into account well established identifiers and user groups which have resources to preserve digital resources for long term. A national library using urn:isbn is not a corner case but a key user group with fairly well specified needs - although I may not be able to express them clearly enough. > > I do think we have fundamental problems with where we are and > where we are headed. One possible conclusion from both your > remarks and concerns and mine is that trying to establish a > single persistent identifier model for arbitrary resources may > have exceeded the IETF's knowledge and competence if, indeed, it > is possible. If that is even partially true, then trying to > define them as an element of a syntax-sharing "uniform resource > identifier" concept was probably a worse idea whether those > identifiers are the URIs described in 3986 and its predecessors > or something else. Yes; RFC 3986 underestimated the complexity of long term preservation and the requirements digital archiving sets for identifiers and resolution services. Everything has to be made as simple as possible but not simpler, said Einstein, and the attempt to replace URLs and URNs with URIs goes to the too simple category. > It would have therefore been much easier > (and more plausible) to define our persistent resource > references separately from persistent resource-class references > and to do so in a way that would be less likely to lead the > naive but well intentioned (much less those who don't think or > don't care) into situations that invite abuse and undermining > the concept. But, even if that very pessimistic analysis of > the problem is the right one, the question today remains how we > move forward to salvage the best of a bad situation, accepting > the actually practices in the field and the potential for > competing standards (or at least IETF standards that are ignored > in practice) as part of the reality we have to consider. If IETF fails to specify how to use fragment and query with URNs, different user communities will invent and re-invent this thing by themselves. The result will be duplicate effort and diminished interoperability. Given that we need to live with persistent identifiers for a long time, I wish this group can agree on principles and produce something useful. If not, the National Library of Finland will develop national standards based on the work done earlier in URNbis. > I've found this discussion very educational, thought-provoking, and > illuminating. It has certainly clarified my thinking. Working with the IETF experts has definitely been all of the above - and sometimes also a little bit frustrating ;-). I have changed my mind about many things during the process, but there is one thing that I must take into account: the current & future technical infrastructure within which libraries shall apply URNs and URN resolution services. This includes the existing identifier systems and their usage policies which cannot be radically adjusted because of URN usage. > I suspect from their silence that most of the rest of the WG's > participants are less enthused or perhaps just waiting for your > promised specific proposal. I don't think that the two-way > conversation will help much more until others step in or your I-D is > posted. So I'm going to go back to lurking and hoping for the best > until one of those things happens. I will comment Keith's proposal next week. All the best, Juha > best, john _______________________________________________ urn mailing > list urn@ietf.org https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 --------------080608000406000700010603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello,

Several comments below.

On 16.6.2013 19:25, John C Klensin wrote:
[snip] While I dislike several things about
3986, I don't see it as nearly as URN-hostile or, for that
matter, different from its predecessors, as you obviously do.
Based on RFC 3986, it is possible to say things like this (quote from http://en.wikipedia.org/wiki/Uniform_resource_name):

Since RFC 3986 in 2005, the use of the term [URN] has been deprecated in favor of the less-restrictive "URI", a view proposed by a joint working group between the W3C and IETF. Both URNs (names) and URLs (locators) are URIs, and a particular URI may be a name and a locator at the same time.

Confusing URNs (identifiers) and URLs (locations) like this and introducing URIs has not been helpful.  There are people whose requirements for persistence can be fulfilled by URLs, but organizations such as national archives, national libraries etc. which must preserve digital contents for centuries cannot trust on anything that is as technology dependent as URLs. For us, there is a fundamental difference between locators and persistent identifiers.   
Nonetheless, I think that getting this right first and then
seeing what, if necessary has to be done to align things with
3968 (or vice versa) is a reasonable strategy.
Agreed. 

That said, I think we need a 2174bis draft to use as the basis
for discussion.  Both in the the absence of a posted alternative
and because I belief that most of what is needed is there, I
would prefer to treat draft-ietf-urnbis-rfc2141bis-urn as that
draft.
Yes, but the latest draft written by Alfred Hoenes does say a lot about fragment and query which can / should be re-used in the next  version of rfc2141bis.

It is important to find a compromise which is acceptable both for IETF (from RFC 3986 point of view) and for communities who are using bibliographic and other identifiers and wish to make them actionable in the Internet. If this WG does not find a solution, then groups using persistent identifiers (Handles, DOIs, URNs and ARKs) will develop their own solutions. This is already happening, and some of the solutions I've seen are completely incompatible with the URI syntax. And even if the requirements of RFC 3986 are followed, interoperability may be in danger.  
...
Yes, I have a similar interpretation, and agree that RESERVED
does not imply "prohibited for all time".   But of course the
reason they were RESERVED is that we didn't know at the time
how to make them work and retain the persistence properties of
URNs.   It's not yet clear to me that we know how to do that
now, but at least I think I personally understand the issues
better than I did then.
URNs have been in use for more than a decade, which will help us this time. And there is also an emerging technical infrastructure for administering and preserving digital content for long term. Persistent identifiers have to fit into this infrastructure, and so that it will be easy to accommodate new functionality when it appears. This means, for instance, that specifying new resolution services and service related parameters is a simple and fast process.  
And yet, people are accustomed to being able to compose URIs
out of base URIs and fragment IDs without having to worry
about whether the result will be valid.   They don't know that
it's stupid to do that, and nothing that 2141bis says is
likely to affect the vast majority of users that are currently
accustomed to appending fragment IDs to URIs.
It is not stupid to add a fragment if one can safely assume that the identified resource will not change. With URLs there is absolutely no guarantee of that. Within the URN system, there are namespaces such as URN:ISBN where fragments will work as long as the user has a tool with which the resource can be used. 

So, ignoring 3986 and reprising somewhat, I am suggesting that
we 

(1) Allow fragment identifiers for URNs with the "#" delimiter
(because switching delimiters to clearly denote these as
"something else from what one might infer from 3986" would cause
far more problems and incompatibility.
OK. But for practical reasons we should make clear that fragment is not part of the NSS and therefore does not identify anything. The fragment indicates just a location within the identified resource and is used by viewing applications once the entire resource has been retrieved.   

(2) Without restricting syntax, make the presence or absence of
fragment identifiers a namespace issue (not a parsing one).
Many namespaces would not be able to use the URI fragment as a part of the NSS, because the identifier system prevents such extensions. If fragment is something that is added to the NSS when needed, this problem disappears. Analyzing semantic equivalence of two URNs is also a lot easier if the fragment can be ignored.    

Generally, URI fragment can be applied in those URN namespaces in which the resolution produces something that has fragments in the URI syntax sense of the word. Specifying in advance which namespaces can use it and which ones cannot may not easy. Manifestation driven namespaces such as ISBN an easy; if I have for instance

urn:isbn:<isbn-number> 

for an XML version of the book, it should be possible to use

urn:isbn:<isbn-number>#chapter2

to indicate the beginning of Chapter 2.  

There are many identifiers / namespaces which do not cover digital resources themselves. But it may still be possible to use fragments. For instance, ISTC (International Standard Text Code) identifies textual works but not their manifestations. Resolving

urn:istc:<istc-number>

will by default produce work level metadata. This URN:

 urn:istc:<istc-number>#author  

would still identify the entire metadata record, but the user should first see the author element within the metadata record.  As an aside,  urn:istc:<istc-number>#author is not the persistent identifier of the author; that would be urn:isni:<isni-number>. 
2141-compliant UNR processors, and processors associated with
older namespaces, will presumably get some flavor of "syntax
error - reserved character" errors or some other failure
condition.  I don't see that as a problem.
If fragments are not part of the NSS, resolvers should just ignore them. And if my memory serves me right, web browsers should not even pass them on along the rest of the URI.

(3) _Require_ that processors for namespaces that do not allow
fragment identifiers respond to their presence with an error
condition, whether that is a slightly-bogus "syntax error" or
"character/fragments not allowed" report (for backward
compatibility) or some flavor of "not allowed" or "not found".
I used to think that there are namespaces in which URI fragment can never be used. But this may not be the case since the fragment applicability depends on resolution services available. We cannot say that using fragment is a priori impossible for e.g. work identifiers such as ISTC.  But there will be situations when it is impossible to add a fragment since the retrieved resource does not support fragment usage. 

(4) _Require_ that processors for namespaces that perform
dereferencing that do allow fragment identifiers (note that, if
2141 were followed, all of these would be new or revised) reject
the things if they don't match identified fragment elements in
the relevant resource.  I expect this requirement will be
ignored in namespaces that are already using fragments, but at
least we will have a clear line about compliance.
OK. 

(5) As discussed earlier, warn about some types of fragment
identifiers are inconsistent with persistence and prohibit them
in URNs for that reason.  I expect this may be ignored as well,
but it will give us a fairly clear line about compliance and at
least won't make anything worse or make the IETF look stupid.
It will be difficult to enforce this if the users utilize fragments after the URNs have been assigned. We cannot assume that they are familiar with persistence limitations. If anything, they will feel more comfortable using fragments with URNs than with URLs. 

(6) Make sure that, from a syntax standpoint, fragment
identifiers are clearly part of the URN and including in the
matching rules.   None of 

    URN:feline:...lion
    URN:feline:...lion#African
    URN:feline:...lion#Asian

Match any of the others.
This is not how libraries, archives and museums intend to use fragments. Our aim is to allow the users to do things like this

urn:isbn:<isbn-number> (assigned by the publisher or the ISBN center)
urn:isbn:<isbn-number>#chapter10 (assigned by a user A)
urn:isbn:<isbn-number>#chapter 27 (assigned by a user B)

and so on. All of these URNs identify the same book and they are semantically equivalent since fragment is not part of the NSS.

As regards the example above, Library of Congress subject headings has 68 hits with "lions" (see http://id.loc.gov/search/?q=lions&q=cs%3Ahttp%3A%2F%2Fid.loc.gov%2Fauthorities%2Fsubjects) including e.g. Lion -- Behavior -- South Africa, but all these have their own identifiers. Fragments are not and will never be used to specify different kind of lions in LCSH.  

I am agnostic about whether different media types that are used within (or dereferenced from) the same namespace should be able to impose their own restrictions on fragments as long as they don't broaden the rules above. Clearly exactly what is permitted to be useful in a fragment (uing the book example again, consider "#Chapter3" versus "Chapter-III") is resource-dependent, not media type dependent. I'd prefer to avoid the complexity of an additional layer of rules so will ask for use cases, but I ultimately don't care very much.

Yes, the precise form of the fragment depends on the encoding of the identified resource. 
...
In my mind at least, a URN shouldn't be associated with a
document or resource, but rather with a resource definition
that explains exactly what is being named, and that resource
definition is part of what you should get back when you
resolve the URN... so that the client has a better idea of how
specific that particular URN is (e.g. is it a particular
document or a particular version of a document or a particular
rendering of a particular version of a document, or something
narrower or broader?)
It would be useful if IETF folks had a good understanding of how libraries etc. will deal with the challenge of long term preservation and what role persistent identifiers will have in that.

If identifier assignment is a managed process (as it should be), different identifiers (URN namespaces) will be used for different purposes. Assuming that the resource is Hamlet, ISTC will be assigned for the work. Resolving the urn:istc will provide metadata record, including URNs of related works (like Hamlet movies), the play's different expressions (translations, illustrated versions, cartoons,...), URNs & URLs of resources about Hamlet, and so on. After selecting e.g. a specific German translation, the user will see its many manifestations.  Eventually he may choose one of them, such as freely available PDF version which looks like a printed book, or EPUB 3 version which adapts itself to the tablet the reader is using. 

So there will be URNs which are associated with the resource, but there will also be many other kinds of URNs, and linking all of them together should help us to provide all users what they want, now and in the (very) distant future. 

But in practice we tend to talk about URNs being persistent
across changes in the document when we actually mean something
more subtle than that, much as we talk about URNs being
persistent when we're really referring to a property of the
binding between the URN and the resource [definition].
Agreed. From library point of view, work identifiers are persistent since works themselves are immaterial and will never change (as a result of changes in e.g. the file format of the resource). Persistence across changes in the document (for instance, as a result of migrating the resource in a new file format) is achieved via mapping the two manifestations and their URNs to one another directly and via the work level record. 


In principle, any URN can refer to any kind of resource.  If
there are particular namespaces that constrain themselves as
to only assign URNs to specific kinds of resources that have
specific persistence properties, that's their business, but we
shouldn't define general URN behavior in the presence of
fragment IDs and/or query strings in such a way that it only
works for those corner cases.
Most well managed URN namespaces are constrained one way or another. I would not call them corner cases but use cases. For me, totally uncontrolled namespace like UUID is a corner case since most resource which have urn:uuid will not be preserved for future generations.

URN should take into account well established identifiers and user groups which have resources to preserve digital resources for long term. A national library using urn:isbn is not a corner case but a key user group with fairly well specified needs - although I may not be able to express them clearly enough.    

I do think we have fundamental problems with where we are and
where we are headed.  One possible conclusion from both your
remarks and concerns and mine is that trying to establish a
single persistent identifier model for arbitrary resources may
have exceeded the IETF's knowledge and competence if, indeed, it
is possible.  If that is even partially true, then trying to
define them as an element of a syntax-sharing "uniform resource
identifier" concept was probably a worse idea whether those
identifiers are the URIs described in 3986 and its predecessors
or something else.
Yes; RFC 3986 underestimated the complexity of long term preservation and the requirements digital archiving sets for identifiers and resolution services. Everything has to be made as simple as possible but not simpler, said Einstein, and the attempt to replace URLs and URNs with URIs goes to the too simple category. 

 It would have therefore been much easier
(and more plausible) to define our persistent resource
references separately from persistent resource-class references
and to do so in a way that would be less likely to lead the
naive but well intentioned (much less those who don't think or
don't care) into situations that invite abuse and undermining
the concept.   But, even if that very pessimistic analysis of
the problem is the right one, the question today remains how we
move forward to salvage the best of a bad situation, accepting
the actually practices in the field and the potential for
competing standards (or at least IETF standards that are ignored
in practice) as part of the reality we have to consider.
If IETF fails to specify how to use fragment and query with URNs, different user communities will invent and re-invent this thing by themselves. The result will be duplicate effort and diminished interoperability. Given that we need to live with persistent identifiers for a long time, I wish this group can agree on principles and produce something useful. If not, the National Library of Finland will develop national standards based on the work done earlier in URNbis. 

I've found this discussion very educational, thought-provoking, and illuminating. It has certainly clarified my thinking.

Working with the IETF experts has definitely been all of the above - and sometimes also a little bit frustrating ;-). I have changed my mind about many things during the process, but there is one thing that I must take into account: the current & future technical infrastructure within which libraries shall apply URNs and URN resolution services. This includes the existing identifier systems and their usage policies which cannot be radically adjusted because of URN usage.  

I suspect from their silence that most of the rest of the WG's participants are less enthused or perhaps just waiting for your promised specific proposal. I don't think that the two-way conversation will help much more until others step in or your I-D is posted. So I'm going to go back to lurking and hoping for the best until one of those things happens.

I will comment Keith's proposal next week.

All the best,

Juha


best, john _______________________________________________ urn mailing list urn@ietf.org https://www.ietf.org/mailman/listinfo/urn 


-- 

 Juha Hakala
 Senior advisor

 The National Library of Finland 
 P.O.Box 15 (Unioninkatu 36, room 503)
 FIN-00014 Helsinki University
 tel +358 9 191 44293
--------------080608000406000700010603-- From john-ietf@jck.com Sat Jul 6 06:37:17 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B411121F9BD3 for ; Sat, 6 Jul 2013 06:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.765 X-Spam-Level: X-Spam-Status: No, score=-101.765 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcATWJKgF73a for ; Sat, 6 Jul 2013 06:37:14 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id B1E2021F9BCF for ; Sat, 6 Jul 2013 06:37:13 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1UvSfl-000A5j-2c; Sat, 06 Jul 2013 09:37:09 -0400 X-Vipre-Scanned: 021F1711002C31021F185E-TDI Date: Fri, 05 Jul 2013 22:05:47 -0400 From: John C Klensin To: Juha Hakala , urn@ietf.org Message-ID: <40BA98D4D3399F1F1597B425@[192.168.1.128]> In-Reply-To: <51D6C1B0.7010004@helsinki.fi> References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <4A9225387F6E4CCB5BB1A018@JcK-HP8200.jck.com> <51BC8D66.9050000@network-heretics.com> <7ED5CCF8F4C22A4918928866@JcK-HP8200.jck.com> <51D6C1B0.7010004@helsinki.fi> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 13:37:17 -0000 Juha, This analysis is very helpful, at least for me. It feels like we are on our way to a discussion, rather than the staking out of positions that I think has sometimes characterized this WG. Detailed comments that I hope will be a step in that discussion inline below. --On Friday, July 05, 2013 15:53 +0300 Juha Hakala wrote: > Hello, > > Several comments below. > > On 16.6.2013 19:25, John C Klensin wrote: >> [snip] While I dislike several things about >> 3986, I don't see it as nearly as URN-hostile or, for that >> matter, different from its predecessors, as you obviously do. > Based on RFC 3986, it is possible to say things like this > (quote from > http://en.wikipedia.org/wiki/Uniform_resource_name): > >> Since RFC >> 3986^> _note-FOOTNOTERFC_39862005-2> in 2005, the use of the term >> [URN] has been deprecated in favor of the less-restrictive >> "URI", a view proposed by a joint working group between the >> W3C and IETF. >> ^> e-FOOTNOTEW3C.2FIETF2001-3> Both URNs (names) and >> URLs >> (locators) are URIs, and a particular URI may be a name and >> a locator at the same time. > > Confusing URNs (identifiers) and URLs (locations) like this > and introducing URIs has not been helpful. There are people > whose requirements for persistence can be fulfilled by URLs, > but organizations such as national archives, national > libraries etc. which must preserve digital contents for > centuries cannot trust on anything that is as technology > dependent as URLs. For us, there is a fundamental difference > between locators and persistent identifiers. I agree with that distinction. I think it is very important and that it should be obvious to anyone who has thought about the information theory/ information science aspects of this, rather than trying to create Grand Unified Theories. As I have said before, I personally would have preferred a URN syntax that was unmistakably not a member of the URI family, but I lost that argument and probably for good reasons. And it was lost, and the URI concept invented, in the 90s, not in 2005. >> Nonetheless, I think that getting this right first and then >> seeing what, if necessary has to be done to align things with >> 3968 (or vice versa) is a reasonable strategy. > Agreed. In particular, what is really important about 3986, at least IMO, is the syntax and the rules that bear directly on it. More philosophical discussions about the relationships among identifier types ought to be possible to clarify without doing any significant harm. >> That said, I think we need a 2174bis draft to use as the basis >> for discussion. Both in the the absence of a posted >> alternative and because I belief that most of what is needed >> is there, I would prefer to treat >> draft-ietf-urnbis-rfc2141bis-urn as that draft. > Yes, but the latest draft written by Alfred Hoenes does say a > lot about fragment and query which can / should be re-used in > the next version of rfc2141bis. > It is important to find a compromise which is acceptable both > for IETF (from RFC 3986 point of view) and for communities who > are using bibliographic and other identifiers and wish to make > them actionable in the Internet. If this WG does not find a > solution, then groups using persistent identifiers (Handles, > DOIs, URNs and ARKs) will develop their own solutions. This is > already happening, and some of the solutions I've seen are > completely incompatible with the URI syntax. And even if the > requirements of RFC 3986 are followed, interoperability may be > in danger. I would prefer to avoid the concept of "compromise". I think there is a reasonable solution lurking out there and that your note contributes to finding it. If that is not the case, we have gotten URNs seriously wrong, wrong enough that we need to do some rather fundemantAal rethinking that might even lead to deprecating them in favor of a different model. I don't believe that is likely to be necessary, but we shouldn't dismiss it out of hand. Otherwise agreed. And that is exactly what has brought me reluctantly back into the discussion. >>> ... >>> Yes, I have a similar interpretation, and agree that RESERVED >>> does not imply "prohibited for all time". But of course the >>> reason they were RESERVED is that we didn't know at the time >>> how to make them work and retain the persistence properties >>> of URNs. It's not yet clear to me that we know how to do >>> that now, but at least I think I personally understand the >>> issues better than I did then. > URNs have been in use for more than a decade, which will help > us this time. And there is also an emerging technical > infrastructure for administering and preserving digital > content for long term. Persistent identifiers have to fit into > this infrastructure, and so that it will be easy to > accommodate new functionality when it appears. This means, for > instance, that specifying new resolution services and service > related parameters is a simple and fast process. >>> And yet, people are accustomed to being able to compose URIs >>> out of base URIs and fragment IDs without having to worry >>> about whether the result will be valid. They don't know >>> that it's stupid to do that, and nothing that 2141bis says is >>> likely to affect the vast majority of users that are >>> currently accustomed to appending fragment IDs to URIs. > It is not stupid to add a fragment if one can safely assume > that the identified resource will not change. With URLs there > is absolutely no guarantee of that. Within the URN system, > there are namespaces such as URN:ISBN where fragments will > work as long as the user has a tool with which the resource > can be used. I think we need to accept two things, both of which should be obvious. (1) URNs and URLs have different semantics (not just permanence properties. As a result, the semantics of, restriction on, and expectations of, fragment identifiers are going to be different, even if the basic syntax framework is the same. (2) >> So, ignoring 3986 and reprising somewhat, I am suggesting that >> we >> >> (1) Allow fragment identifiers for URNs with the "#" delimiter >> (because switching delimiters to clearly denote these as >> "something else from what one might infer from 3986" would >> cause far more problems and incompatibility. > OK. But for practical reasons we should make clear that > fragment is not part of the NSS and therefore does not > identify anything. The fragment indicates just a location > within the identified resource and is used by viewing > applications once the entire resource has been retrieved. Works for me. Perhaps the "once...has been retrieved" requirement is part of the rational boundary between (using a book as an example) "URNs points to book, fragment marks chapter beginning" and "URNs point to chapters with multiple URNs per book and the book considered as a collection of chapters rather than an object". >> (2) Without restricting syntax, make the presence or absence >> of fragment identifiers a namespace issue (not a parsing one). > Many namespaces would not be able to use the URI fragment as a > part of the NSS, because the identifier system prevents such > extensions. If fragment is something that is added to the NSS > when needed, this problem disappears. Analyzing semantic > equivalence of two URNs is also a lot easier if the fragment > can be ignored. Again, works for me if we can get agreement on it. > Generally, URI fragment can be applied in those URN namespaces > in which the resolution produces something that has fragments > in the URI syntax sense of the word. Specifying in advance > which namespaces can use it and which ones cannot may not > easy. Manifestation driven namespaces such as ISBN an easy; if > I have for instance > > urn:isbn: > > for an XML version of the book, it should be possible to use > > urn:isbn:#chapter2 > > to indicate the beginning of Chapter 2. > > There are many identifiers / namespaces which do not cover > digital resources themselves. But it may still be possible to > use fragments. For instance, ISTC (International Standard Text > Code) identifies textual works but not their manifestations. > Resolving > > urn:istc: > > will by default produce work level metadata. This URN: > > urn:istc:#author > > would still identify the entire metadata record, but the user > should first see the author element within the metadata > record. As an aside, urn:istc:#author is not > the persistent identifier of the author; that would be > urn:isni:. I think I understand that. If I do, I think it interacts with the old problem (and one to which Keith's notes refer) of distinguishing between "URN as name for object/resource" and "URN as name for a pointer to something that leads to a resource". It might have been better had we separately those in syntax or URI type identifiers, but too late for that. I'd also encourage folks to have a look at https://datatracker.ietf.org/doc/draft-faltstrom-uri. In one sense, this is just NAPTR revisited, but, to the extent to which a URI can reference a DNS name that could reference a URN that, in turn, could involve or reference a mechanism for getting to an object, we could find ourselves quite deep in levels of abstraction and references. While necessary sometimes, layered references as probably the enemy of persistence and stability assertions in many cases. >> 2141-compliant UNR processors, and processors associated with >> older namespaces, will presumably get some flavor of "syntax >> error - reserved character" errors or some other failure >> condition. I don't see that as a problem. > If fragments are not part of the NSS, resolvers should just > ignore them. And if my memory serves me right, web browsers > should not even pass them on along the rest of the URI. > >> (3) _Require_ that processors for namespaces that do not allow >> fragment identifiers respond to their presence with an error >> condition, whether that is a slightly-bogus "syntax error" or >> "character/fragments not allowed" report (for backward >> compatibility) or some flavor of "not allowed" or "not found". > I used to think that there are namespaces in which URI > fragment can never be used. But this may not be the case since > the fragment applicability depends on resolution services > available. We cannot say that using fragment is a priori > impossible for e.g. work identifiers such as ISTC. But there > will be situations when it is impossible to add a fragment > since the retrieved resource does not support fragment usage. ok >> (4) _Require_ that processors for namespaces that perform >> dereferencing that do allow fragment identifiers (note that, >> if 2141 were followed, all of these would be new or revised) >> reject the things if they don't match identified fragment >> elements in the relevant resource. I expect this requirement >> will be ignored in namespaces that are already using >> fragments, but at least we will have a clear line about >> compliance. > OK. >> >> (5) As discussed earlier, warn about some types of fragment >> identifiers are inconsistent with persistence and prohibit >> them in URNs for that reason. I expect this may be ignored >> as well, but it will give us a fairly clear line about >> compliance and at least won't make anything worse or make the >> IETF look stupid. > It will be difficult to enforce this if the users utilize > fragments after the URNs have been assigned. We cannot assume > that they are familiar with persistence limitations. If > anything, they will feel more comfortable using fragments with > URNs than with URLs. >> >> (6) Make sure that, from a syntax standpoint, fragment >> identifiers are clearly part of the URN and including in the >> matching rules. None of >> >> URN:feline:...lion >> URN:feline:...lion#African >> URN:feline:...lion#Asian >> >> Match any of the others. > This is not how libraries, archives and museums intend to use > fragments. Our aim is to allow the users to do things like this > > urn:isbn: (assigned by the publisher or the ISBN > center) > urn:isbn:#chapter10 (assigned by a user A) > urn:isbn:#chapter 27 (assigned by a user B) > > and so on. All of these URNs identify the same book and they > are semantically equivalent since fragment is not part of the > NSS. > > As regards the example above, Library of Congress subject > headings has 68 hits with "lions" (see > http://id.loc.gov/search/?q=lions&q=cs%3Ahttp%3A%2F%2Fid.loc.g > ov%2Fauthorities%2Fsubjects) including e.g. Lion -- Behavior > -- South Africa, but all these have their own identifiers. > Fragments are not and will never be used to specify different > kind of lions in LCSH. I'm persuaded, or at least nearly so. I think what is most important is that either fragments are unambiguously part of the URN (for matching and retrieval purposes) or they are not. >... >>> ... >>> In my mind at least, a URN shouldn't be associated with a >>> document or resource, but rather with a resource definition >>> that explains exactly what is being named, and that resource >>> definition is part of what you should get back when you >>> resolve the URN... so that the client has a better idea of >>> how specific that particular URN is (e.g. is it a particular >>> document or a particular version of a document or a >>> particular rendering of a particular version of a document, >>> or something narrower or broader?) > It would be useful if IETF folks had a good understanding of > how libraries etc. will deal with the challenge of long term > preservation and what role persistent identifiers will have in > that. > > If identifier assignment is a managed process (as it should > be), different identifiers (URN namespaces) will be used for > different purposes. Assuming that the resource is Hamlet, ISTC > will be assigned for the work. Resolving the urn:istc will > provide metadata record, including URNs of related works (like > Hamlet movies), the play's different expressions > (translations, illustrated versions, cartoons,...), URNs & > URLs of resources about Hamlet, and so on. After selecting > e.g. a specific German translation, the user will see its many > manifestations. Eventually he may choose one of them, such as > freely available PDF version which looks like a printed book, > or EPUB 3 version which adapts itself to the tablet the reader > is using. > > So there will be URNs which are associated with the resource, > but there will also be many other kinds of URNs, and linking > all of them together should help us to provide all users what > they want, now and in the (very) distant future. That is all completely reasonable and understandable, modulo the concerns about undifferentiated layers of references above. Perhaps that is not a problem, but it seems to me to have the potential for a lot of complexity, referencing loops, etc. I also wonder a bit about your "managed" assertion. I think it is safe to assume that some namespaces will be a lot more managed than others and that many of them will face the perennial problem with groups of Internet identifiers: the inability to compel use of the management or registration process if someone wants to go their own way. >>> But in practice we tend to talk about URNs being persistent >>> across changes in the document when we actually mean >>> something more subtle than that, much as we talk about URNs >>> being persistent when we're really referring to a property >>> of the binding between the URN and the resource [definition]. > Agreed. From library point of view, work identifiers are > persistent since works themselves are immaterial and will > never change (as a result of changes in e.g. the file format > of the resource). Persistence across changes in the document > (for instance, as a result of migrating the resource in a new > file format) is achieved via mapping the two manifestations > and their URNs to one another directly and via the work level > record. >> In principle, any URN can refer to any kind of resource. If >> there are particular namespaces that constrain themselves as >> to only assign URNs to specific kinds of resources that have >> specific persistence properties, that's their business, but we >> shouldn't define general URN behavior in the presence of >> fragment IDs and/or query strings in such a way that it only >> works for those corner cases. > Most well managed URN namespaces are constrained one way or > another. I would not call them corner cases but use cases. For > me, totally uncontrolled namespace like UUID is a corner case > since most resource which have urn:uuid will not be preserved > for future generations. > > URN should take into account well established identifiers and > user groups which have resources to preserve digital resources > for long term. A national library using urn:isbn is not a > corner case but a key user group with fairly well specified > needs - although I may not be able to express them clearly > enough. yes, but I think you and others are going to have to continue to educate the rest of us if URNs are going to succeed. I appreciate your patience and willingness to do so. >> I do think we have fundamental problems with where we are and >> where we are headed. One possible conclusion from both your >> remarks and concerns and mine is that trying to establish a >> single persistent identifier model for arbitrary resources may >> have exceeded the IETF's knowledge and competence if, indeed, >> it is possible. If that is even partially true, then trying >> to define them as an element of a syntax-sharing "uniform >> resource identifier" concept was probably a worse idea >> whether those identifiers are the URIs described in 3986 and >> its predecessors or something else. > Yes; RFC 3986 underestimated the complexity of long term > preservation and the requirements digital archiving sets for > identifiers and resolution services. Everything has to be made > as simple as possible but not simpler, said Einstein, and the > attempt to replace URLs and URNs with URIs goes to the too > simple category. See above about fixing statements of philosophy. >... >> I've found this discussion very educational, >> thought-provoking, and illuminating. It has certainly >> clarified my thinking. > Working with the IETF experts has definitely been all of the > above - and sometimes also a little bit frustrating ;-). I > have changed my mind about many things during the process, but > there is one thing that I must take into account: the current > & future technical infrastructure within which libraries shall > apply URNs and URN resolution services. This includes the > existing identifier systems and their usage policies which > cannot be radically adjusted because of URN usage. At the same time, I think all of us need to understand that not all URNs (and namespaces) are the same and need to be treated the same way. For some, the experience and constraints of libraries, archives, and similar systems are critical and should at least set boundary conditions on the discussion and options. For others, different considerations may apply. Unless I'm missing something. one thing that is going to turn out to be important will be identifying the differences and which namespaces fall into which categories and being clear about that. >> I suspect from their silence that most of the rest of the >> WG's participants are less enthused or perhaps just waiting >> for your promised specific proposal. I don't think that the >> two-way conversation will help much more until others step >> in or your I-D is posted. So I'm going to go back to lurking >> and hoping for the best until one of those things happens. > > I will comment Keith's proposal next week. Thanks. john From john-ietf@jck.com Sun Jul 7 06:59:10 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFFC21F9F1B for ; Sun, 7 Jul 2013 06:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.182 X-Spam-Level: X-Spam-Status: No, score=-102.182 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fsi4Dxs33fNZ for ; Sun, 7 Jul 2013 06:59:05 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id A603221F9F15 for ; Sun, 7 Jul 2013 06:59:05 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1UvpUS-000Cfc-NI; Sun, 07 Jul 2013 09:59:00 -0400 X-Vipre-Scanned: 02A8B9CE002C3102A8BB1B-TDI Date: Sun, 07 Jul 2013 09:58:59 -0400 From: John C Klensin To: Keith Moore , Barry Leiba Message-ID: <65823B328A8C0AC3E24F5E84@localhost> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: urn@ietf.org Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 13:59:10 -0000 Hi. Trying to pick back up on this after being distracted by some other issues for the last couple of weeks. I'm going to reply to the correspondence between Pete and Barry from two weeks ago because it is a convenient anchor, but have read all the traffic until now. I sent a separate response to Juha's main comments Friday. --On Friday, June 21, 2013 11:09 -0400 Keith Moore wrote: > On 06/21/2013 10:51 AM, Barry Leiba wrote: >> I'll also note that I see a reasonable case for fragments >> actually changing what resource the URN winds up resolving >> to. Consider this: "urn:isbn:0-679-40758-8" would name the >> edition of "Don Quixote" that I have on my bookshelf. It's a >> big book; it has, in one cover, "Volume 1" (which subdivides >> into "Book I" through "Book IV") and "Volume 2" (which has >> "Book V" and "Book VI"). If fragments were allowed, it might >> be reasonable for, say, >> "urn:isbn:0-679-40758-8#volume.1" to get me to >> "http://example.com/don-quixote/vol1", and for >> "urn:isbn:0-679-40758-8:volume.2" to get me to Barry, I see where you are headed here, but I think it leads to madness, at least as I understand URNs. From that perspective, there are two rational choices: One is to treat the entire two-volume "book" (with an ISBN assigned independent of the "volume" boundary). For that case, Juha's notion of "the URN identifies the 'book' and any fussing with fragment IDs occurs after retrieval time" might work well if some performance issues are ignored. There are some subtle issues with that which I'll let Juha, or, if she has joined the list by now, Stella Griffiths, comment on, but one of them is whether it is appropriate to assign one ISBN to a two-volume set and, if it is, if it is appropriate to then treat that set as anything other than atomic (i.e., an artifact of binding as far as the ISBN is concerned, perhaps such that an otherwise-identical printing on really thin paper and bound as one volume would get the same ISBN. But, if the ISBN really refers to an atomic "book" unit, then "urn:isbn:0-679-40758-8#book.iii" would be perfectly reasonable, but "urn:isbn:0-679-40758-8#volume.1" is nonsense -- not with regard to your mental picture or what you see on your shelf, but with regard to the intrinsic properties if ISBN assignments and hence with the ISBN namespace. It is that sort of issue which caused me to say "namespace dependent". If one has any delusions about fragments being part of the resolution process on the server, then it seems to me that standards for what is valid and what isn't have to be set as part of the definition of the namespace and that, if the namespace is itself dependent on what I think Juha would call a formally managed process (language supported by RFC 3406), by the agency that defines and interprets that process. The other possibility is to treat fragments as not part of the URN dereferencing (see below) process but as part of a discussion between the user who specifies a URN to a user interface and that interface, not the URN-resolving server. What makes this more interesting is that, if I correctly understand the ISBN rules, it would be possible for a publisher of an electronic version to assign separate ISBNs to the various books of Cervantes's original organization. That would make it quite plausible to refer to "Don-Quixote-book3" by "URN:ISBN:0-679-NNNNN-N" and to "Don-Quixote-book4" by "URN:ISBN"0-679-MMMMM-M" but that obviously has nothing to do with fragments. If one wants to treat all printings or editions as the same, then URNs and fragments aren't the problem. The problem is that ISBNs are just not the right tool. >> The critical part here is that what we define has to be >> useful to the folks who will actually *use* the URNs in the >> real world, and I think that's where John's proposal takes >> us. If they don't need fragments as part of the URNs (or >> queries, which I find much more problematic as anything other >> than something that's passed to the resource), then we're >> fine in saying that they're not part of the URNs. But if they >> *do* (because they need to do the sorts of things above, or >> perhaps because they need to do something entirely different >> and I got it all wrong), then we have to allow them to do >> what they actually have to do -- otherwise, we'll have simply >> defined some architecturally pure thing that's not actually >> useful. Indeed, that is consistent with the point I was trying to make. > I've had a couple of ideas about this: > > 1. One is that URN resolution of a resource could return a > list of fragment mappings. So if you resolved > urn:isbn:0-679-40758-8 you might get back something that > included: > ... > "fragments" = { ( "volume.1" = > "http://example.com/don-quixote/vol1" ), > ( "volume.2" = > "http://example.com/don-quixote/vol2" ), > ( "book.i" = > "http://example.com/don-quixote/vol1#bk1" ), > ( "book.ii" = > "http://example.com/don-quixote/vol1#bk2" ), > ( "book.iii" = > "http://example.com/don-quixote/vol1#bk3" ), > ( "book.iv" = > "http://example.com/don-quixote/vol1#bk4" ), > ( "book.v" = > "http://example.com/don-quixote/vol2#bk5" ), > ( "book.vi" = > "http://example.com/don-quixote/vol2#bk6" ) } > ... Arggh. I think this ignores what ISBNs actually are. It is the collision between our engineering speculations and theories and the reality of well-established identifier systems that represent consensus and extensive practices with their own rules that gets us into trouble here. I suppose one could establish a reference-to-book-that-happens-to-be-identified-by-an-ISBN URI (I have no opinion as to whether that would be a URN or not) that would have the above properties. However, whatever sort of critter that was, it wouldn't be an ISBN URN because the ISBN is perfectly clear about what is being identified and is isn't a collection or URLs that locate fragments. > (Note that there's no real reason that, for an electronic > copy, it would actually be needed to split this work into the > equivalent of two volumes. Though maybe you could have such > a case for a work that required several terabytes of storage.) My supposition from having read the ISBN standard (but certainly not being an expert on it) is that, if one ISBN has been assigned, the "two volume" property is an artifact. And see above about ISBN-per-Book. > 2. Another idea is that you might need separate mechanisms to > permit identifiers to refer to HTML-style fragments, than > those used to refer to persistent fragments. For consistency > with other URIs that refer to HTML-style fragments I'd > recommend continuing to use the '#' notation for these. But > using the syntax I proposed, you could define a /region=xxx > option (call it something different than fragment to minimize > the potential for confusion). And I'm thinking that all such > options should be input to any resolution service (so the > client wouldn't have to know which options applied at which > layer), so the resolution service would see that the client > wanted region "book.iv" and could return the right URL (if not > the whole list of regions). This gives me a nasty headache. But, at least the way I read 3896, there is nothing that requires the semantics of fragments to be constant across URI types (or even across resources). > In summary, I do see the potential that some fragment-like > construct that were resolved as part of the URN could be > useful. I just don't think it's a good idea to prevent users > from addressing individual HTML-style fragments of a document > in conjunction with URNs. And I think it would be confusing > if we repurposed '#' to mean something subtly different for > URNs than for other URIs. See above. At present, fragments are subtly different for different resources even within the HTTP URL environment. Requiring them to somehow be consistent between URLs and URNs when they aren't consistent within URLs strikes me as hard. Picking up text from another note: --On Friday, June 21, 2013 19:13 -0400 Keith Moore wrote: >... > Also, URNs were never intended to be just another URI scheme. > They were always intended to be stable, location-independent > names that resolved to URLs. I just don't think that is true. We've talked about URNs that can't be resolved at all, much less to URLs. That is quite explicitly mentioned, with "resolution" even in quotes, in RFC 3406. That document, incidentally, contains the statement "not all strings that conform to URN syntax are necessarily valid URNs". Exactly that same language appears in RFC 2611, so, to the extent that is a problem, it is hard to blame it entirely on RFC 3986. Suggestion: My guess is that this conversation would be considerably clarified if we stopped talking about "resolving" in favor of "dereferencing" and avoided trying to distinguish "what is part of a URN" or not in favor of distinctions about what what happens on the relevant server and what happens post-retrieval or post-dereferencing (not the same thing either, obviously). best, john From juha.hakala@helsinki.fi Mon Jul 8 01:27:13 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C7511E81B7 for ; Mon, 8 Jul 2013 01:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.254 X-Spam-Level: X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg4y71g2HIrf for ; Mon, 8 Jul 2013 01:27:01 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD7E21F9E41 for ; Mon, 8 Jul 2013 01:24:32 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r688N2WZ007353 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Mon, 8 Jul 2013 11:23:04 +0300 Message-ID: <51DA76E6.6040005@helsinki.fi> Date: Mon, 08 Jul 2013 11:23:02 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: urn@ietf.org References: <65823B328A8C0AC3E24F5E84@localhost> In-Reply-To: <65823B328A8C0AC3E24F5E84@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 08:27:14 -0000 Hello, On 7.7.2013 16:58, John C Klensin wrote: >> On 06/21/2013 10:51 AM, Barry Leiba wrote: >>> I'll also note that I see a reasonable case for fragments >>> actually changing what resource the URN winds up resolving >>> to. This would extend the scope of the URI/URN fragment well beyond what is desirable, and also make it a lot harder to manage the identifier assignment process. >>> Consider this: "urn:isbn:0-679-40758-8" would name the >>> edition of "Don Quixote" that I have on my bookshelf. It's a >>> big book; it has, in one cover, "Volume 1" (which subdivides >>> into "Book I" through "Book IV") and "Volume 2" (which has >>> "Book V" and "Book VI"). If fragments were allowed, it might >>> be reasonable for, say, >>> "urn:isbn:0-679-40758-8#volume.1" to get me to >>> "http://example.com/don-quixote/vol1", and for >>> "urn:isbn:0-679-40758-8:volume.2" to get me to > Barry, I see where you are headed here, but I think it leads to > madness, at least as I understand URNs. In the real world, printed versions of Don Quijote will get different ISBN than the digital versions. And the (separately published) volumes of the digital Don Quijote will each get their own ISBNs. Iff there is a one volume digital version (with a single ISBN) which is encoded so that the beginning of each part can be indicated with a fragment, then fragment usage will be OK - but they will not identify the parts, they just indicate the starting position of each part within the all-encompassing volume. Examples such as the one Barry has provided above illustrate why identifier assignment has to be a managed process. There is a reason why the ISBN community has not only the standard but also an extensive guide book which tells how ISBNs should be used. And perhaps all this complexity also explains why some publishers and ISBN centers occasionally get it wrong ;-). One reason why we need rules and principles for usage of fragment is to prevent people from doing things which are technically possible, but would undermine the appropriate principles for naming documents within that namespace. Of course there will be namespaces where anything goes. But if we were to say that fragment (or query) is part of the NSS, it would be necessary to revise the ISBN standard and all the other existing standard identifiers so that the usage of URI fragments is taken into account. I doubt anybody wants to go into that, for various reasons (most likely many communities would just say no). The easiest solution is to keep both fragments and queries separate from the NSS, which a priori means that a URN and the same URN with fragment always identify the same resource. > It is that sort of issue which caused me to say "namespace dependent". > If one has any delusions about fragments being part of the resolution > process on the server, then it seems to me that standards for what is > valid and what isn't have to be set as part of the definition of the > namespace and that, if the namespace is itself dependent on what I > think Juha would call a formally managed process (language supported > by RFC 3406), by the agency that defines and interprets that process. Many documents have component parts which must be identified separately. For instance, there are periodicals (identified with ISSN) plus periodical issues, articles in those issues, and images within those articles, all of which can be identified by e.g. national bibliography numbers. In order to facilitate long term preservation, typical approach is to give identifiers to everything and not use fragments within e.g. the serial issue to indicate its component parts. This means that URN resolution is used to access "logical fragments" such as journal articles, but URN fragments have nothing to do with the process. > The other possibility is to treat fragments as not part of the URN > dereferencing (see below) process but as part of a discussion between > the user who specifies a URN to a user interface and that interface, > not the URN-resolving server. What makes this more interesting is > that, if I correctly understand the ISBN rules, it would be possible > for a publisher of an electronic version to assign separate ISBNs to > the various books of Cervantes's original organization. Correct. If the book is published in four volumes, there should be one ISBN for the whole book, and each volume should also get its own ISBN. In practice, ISBN assignment is largely based on the needs of the trade: one can buy either the entire book (all volumes) or just one volume; therefore there is a need to separate them. > That would make it quite plausible to refer to "Don-Quixote-book3" by > "URN:ISBN:0-679-NNNNN-N" and to "Don-Quixote-book4" by > "URN:ISBN"0-679-MMMMM-M" but that obviously has nothing to do with > fragments. If one wants to treat all printings or editions as the > same, then URNs and fragments aren't the problem. The problem is that > ISBNs are just not the right tool. Yes - if somebody wants to find for instance all the editions of Don Quixote in English, then ISTC is the identifier to use. >> I've had a couple of ideas about this: >> >> 1. One is that URN resolution of a resource could return a >> list of fragment mappings. So if you resolved >> urn:isbn:0-679-40758-8 you might get back something that >> included: >> ... >> "fragments" = { ( "volume.1" = >> "http://example.com/don-quixote/vol1" ), >> ( "volume.2" = >> "http://example.com/don-quixote/vol2" ), >> ( "book.i" = >> "http://example.com/don-quixote/vol1#bk1" ), >> ( "book.ii" = >> "http://example.com/don-quixote/vol1#bk2" ), >> ( "book.iii" = >> "http://example.com/don-quixote/vol1#bk3" ), >> ( "book.iv" = >> "http://example.com/don-quixote/vol1#bk4" ), >> ( "book.v" = >> "http://example.com/don-quixote/vol2#bk5" ), >> ( "book.vi" = >> "http://example.com/don-quixote/vol2#bk6" ) } >> ... > Arggh. I think this ignores what ISBNs actually are. It is the > collision between our engineering speculations and theories and > the reality of well-established identifier systems that > represent consensus and extensive practices with their own rules > that gets us into trouble here. + 1 (This is just an example.) According to the ISBN assignment rules, there should be an ISBN for e.g. an English translation of Don Quixote published by Victor Gollancz in EPUB 3 (all six volumes), and in addition each volume should have its own ISBN. If the service the user wants is URN to URLs, then the URN:ISBN of the whole thing should resolve to a list of six URLs. On the other hand, URN:ISBN of a single volume will resolve to single URL (provided that there is only one location from which the book can be retrieved; often there are many). Within the technical limitations of the EPUB version, anyone should be able to cite / refer to the chapters etc. within the volumes using URI fragments. But these fragments do not identify chapters. In some circumstances it might be useful to have a URN resolution service (available via a query parameter) which harvests the structure of the document (chapters, parts, names of articles within a book which consists of articles). But since the encoding of the documents can be non-informative, it is a better idea to check descriptive metadata to find out about the resource. Table of contents is probably much more readable than any fragment listing. > >> 2. Another idea is that you might need separate mechanisms to >> permit identifiers to refer to HTML-style fragments, than >> those used to refer to persistent fragments. For consistency >> with other URIs that refer to HTML-style fragments I'd >> recommend continuing to use the '#' notation for these. But >> using the syntax I proposed, you could define a /region=xxx >> option (call it something different than fragment to minimize >> the potential for confusion). And I'm thinking that all such >> options should be input to any resolution service (so the >> client wouldn't have to know which options applied at which >> layer), so the resolution service would see that the client >> wanted region "book.iv" and could return the right URL (if not >> the whole list of regions). > This gives me a nasty headache. But, at least the way I read > 3896, there is nothing that requires the semantics of fragments > to be constant across URI types (or even across resources). My preference is to get started with HTML-style fragments using the #-notation, and to provide basic guidelines for development of namespace specific solutions. This is what Alfred Hoenes and myself were already doing in the previous versions of URNbis I-Ds. There are a lot of projects etc. out there which are hoping to identify component parts of resources. These component parts may be for instance concepts in a corpus database, or variables within research data sets. The 1000 USD question is whether it is possible / advisable to use generic URN syntax tools for this. I do not think so. Given the diversity of the URN namespaces, it is not likely that we can find a generic syntax that would work for everyone. But this is not even necessary. What we need to say is that each namespace may have its own practices for identification of component parts of resources, as long as they do not conflict with URI syntax and there are resolution services which can deal with the resulting URNs. For identification of component parts of resources ("logical fragments") one should never use URI fragments, but identifiers created on the basis of namespace specific practices which must be supplied in the namespace registration request. For the ISBN namespace the principle is carved in stone in the standard: one can assign ISBN for e.g. a chapter of a book (like chapter 1 of Don Quixote, vol. 1) if the chapter is available as a separate item. For NBN, each organization assigning identifiers has the freedom to decide what to do within its own sub-namespace. >> In summary, I do see the potential that some fragment-like >> construct that were resolved as part of the URN could be >> useful. I just don't think it's a good idea to prevent users >> from addressing individual HTML-style fragments of a document >> in conjunction with URNs. And I think it would be confusing >> if we repurposed '#' to mean something subtly different for >> URNs than for other URIs. + 1 to all of the above, except that I think that the best we can have is namespace specific fragment-like constructs. Juha -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 From juha.hakala@helsinki.fi Mon Jul 8 03:33:26 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC36C21F8C40 for ; Mon, 8 Jul 2013 03:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.54 X-Spam-Level: X-Spam-Status: No, score=-4.54 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_20=-0.74, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyztH67z5xId for ; Mon, 8 Jul 2013 03:33:21 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 56A6621F9ED3 for ; Mon, 8 Jul 2013 03:33:21 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r68AXHML023539 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 8 Jul 2013 13:33:18 +0300 Message-ID: <51DA956D.9070008@helsinki.fi> Date: Mon, 08 Jul 2013 13:33:17 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John C Klensin References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <4A9225387F6E4CCB5BB1A018@JcK-HP8200.jck.com> <51BC8D66.9050000@network-heretics.com> <7ED5CCF8F4C22A4918928866@JcK-HP8200.jck.com> <51D6C1B0.7010004@helsinki.fi> <40BA98D4D3399F1F1597B425@[192.168.1.128]> In-Reply-To: <40BA98D4D3399F1F1597B425@[192.168.1.128]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 10:33:26 -0000 Hello, On 6.7.2013 5:05, John C Klensin wrote: > Juha, > > This analysis is very helpful, at least for me. It feels like > we are on our way to a discussion, rather than the staking out > of positions that I think has sometimes characterized this WG. When the URN system were developed there were fewer issues between IETF and the communities using identifiers such as libraries. It looks like after a decade of using URNs the gap between theory and practice seems to have become wider. It is possible that this time the user communities have specific requirements, and finding an acceptable way of implementing them has been hard. Some of the issues we have faced have been fully justified, but sometimes theoretical discussions about the principles of identification on this list have established problems that are not really there. There are quite a few persistent identifiers (PIDs) in use. Among the three most popular ones - Handle, DOI and URN - only URN is under IETF's wing. All of these identifiers are older than RFC 3986 and do not support either query or fragment. If URNbis succeeds in adding them to URN syntax, Handle and DOI may follow - which would not be a bad thing. > I personally would have preferred a URN syntax that was > unmistakably not a member of the URI family, but I lost that > argument and probably for good reasons. And it was lost, and > the URI concept invented, in the 90s, not in 2005. I would like to see the arguments in favour of one URI to rule them all. >>> Nonetheless, I think that getting this right first and then >>> seeing what, if necessary has to be done to align things with >>> 3968 (or vice versa) is a reasonable strategy. >> Agreed. > In particular, what is really important about 3986, at least > IMO, is the syntax and the rules that bear directly on it. More > philosophical discussions about the relationships among > identifier types ought to be possible to clarify without doing > any significant harm. I have assumed for quite a while now that we cannot divert from URI generic syntax. Such diversions are possible when using PIDs; there is a project using Handles which chose to use "@" as the fragment separator. But resolving such URIs correctly requires special software (in the case above, a tuned Handle resolver) and in the long term breaking URI syntax (or making private extensions to Handle syntax) is likely to be risky. Unfortunately persistent identifiers are for long term... > >> It is important to find a compromise which is acceptable both >> for IETF (from RFC 3986 point of view) and for communities who >> are using bibliographic and other identifiers and wish to make >> them actionable in the Internet. If this WG does not find a >> solution, then groups using persistent identifiers (Handles, >> DOIs, URNs and ARKs) will develop their own solutions. This is >> already happening, and some of the solutions I've seen are >> completely incompatible with the URI syntax. And even if the >> requirements of RFC 3986 are followed, interoperability may be >> in danger. > I would prefer to avoid the concept of "compromise". I think > there is a reasonable solution lurking out there and that your > note contributes to finding it. If that is not the case, we > have gotten URNs seriously wrong, wrong enough that we need to > do some rather fundemantAal rethinking that might even lead to > deprecating them in favor of a different model. I don't believe > that is likely to be necessary, but we shouldn't dismiss it out > of hand. Please keep in mind that tens of millions of URNs have been assigned already. They cannot be deprecated, and we cannot make any fundamental changes which would render old and new URNs non-interoperable. What we can do is to add new functionality, such as fragments and queries, and make it easier for people to use URNs by for instance changing the way in which services are registered. >> It is not stupid to add a fragment if one can safely assume >> that the identified resource will not change. With URLs there >> is absolutely no guarantee of that. Within the URN system, >> there are namespaces such as URN:ISBN where fragments will >> work as long as the user has a tool with which the resource >> can be used. > I think we need to accept two things, both of which should be > obvious. (1) URNs and URLs have different semantics (not just > permanence properties. As a result, the semantics of, > restriction on, and expectations of, fragment identifiers are > going to be different, even if the basic syntax framework is the > same. (2) IMO, fragment is just a fragment, no matter whether it is attached to URL or to URN. Even when added to a URN it does not identify anything. Same functionality is expected; the viewing application should take the user to the indicated location within the resource. From functional point of view the main difference is that URL + fragment combination is much more fragile than URN + fragment. Document available in address X may change any time, but document with URN should not change, although it may be moved to a different location. If and when we decide to use query, then URN will have a set of services and service parameters that have been specified as queries. For URLs nothing will be carved in stone like this. >> OK. But for practical reasons we should make clear that >> fragment is not part of the NSS and therefore does not >> identify anything. The fragment indicates just a location >> within the identified resource and is used by viewing >> applications once the entire resource has been retrieved. > Works for me. Perhaps the "once...has been retrieved" > requirement is part of the rational boundary between (using a > book as an example) "URNs points to book, fragment marks chapter > beginning" and "URNs point to chapters with multiple URNs per > book and the book considered as a collection of chapters rather > than an object". OK. > I think what is most > important is that either fragments are unambiguously part of the > URN (for matching and retrieval purposes) or they are not. Yes, we cannot allow both options. In practice, the only feasible option is that URI fragments are not part of the NSS, which means that they may be added to the URN, but from the point of resolution and semantic equivalence the URN is still the same. For those who need to identify component parts ("fragments") of resources, the URN syntax should provide a means of doing that in a namespace specific manner. > So there will be URNs which are associated with the resource, but > there will also be many other kinds of URNs, and linking all of them > together should help us to provide all users what they want, now and > in the (very) distant future. > That is all completely reasonable and understandable, modulo the > concerns about undifferentiated layers of references above. > Perhaps that is not a problem, but it seems to me to have the > potential for a lot of complexity, referencing loops, etc. Long term preservation based on migration will involve a lot of complexity. Over time there will be multiple versions of every resource that can be migrated, and a lot of supporting administrative metadata which describes the differences between successive versions of the document. In order to make sense of all this, librarians have developed models such as FRBR (Functional Requirements for Bibliographic Records) http://en.wikipedia.org/wiki/Functional_Requirements_for_Bibliographic_Records which describe how the different components of the system relate to one another. FRBR does not prevent the possibility of referencing loop, but a proper implementation of the model should not lead the users astray. On the other hand, making a complex model like FRBR work, we need persistent links between e.g. work and manifestation records. Experiments which have used database internal URLs have proven that. > > I also wonder a bit about your "managed" assertion. I think it > is safe to assume that some namespaces will be a lot more > managed than others and that many of them will face the > perennial problem with groups of Internet identifiers: the > inability to compel use of the management or registration > process if someone wants to go their own way. Probably the main difference between Handle and DOI is that DOIs are better managed. There has been problems with DOI (a publisher purchasing a journal, and then changing the DOIs of all the articles) but they are less common than with Handles. With URN there will be a lot of differences between namespaces. There is no management at all with UUID, and there may be namespaces where no resolution is provided, in which case any centralised management is a priori not necessary. Poor service level (which will look like low reliability to the users) in some URN namespaces may undermine the value of the entire URN system. Therefore I regret the fact that it has been so easy to register URN namespaces. At least there should be an organization responsible of the namespace, in case there are questions about it. > URN should take into account well established identifiers and > user groups which have resources to preserve digital resources > for long term. A national library using urn:isbn is not a > corner case but a key user group with fairly well specified > needs - although I may not be able to express them clearly > enough. > yes, but I think you and others are going to have to continue to > educate the rest of us if URNs are going to succeed. I > appreciate your patience and willingness to do so. A particular strength of the URN system compared with other persistent identifiers is that it is fully compliant with existing bibliographic and other identifier systems. URN does not rival the old identifiers by specifying a new identifier system (unlike DOI, Handle and ARK); instead, with URN namespaces all the rules can be aligned according to the specific needs of the identifier community in question. ISBN embedded into URN can be extracted and parsed easily; ISBN embedded into DOI needs a lot more work (since part of ISBN goes into DOI prefix, and other part into DOI suffix, and it is not obvious that the DOI string is an ISBN). > At the same time, I think all of us need to understand that not > all URNs (and namespaces) are the same and need to be treated > the same way. For some, the experience and constraints of > libraries, archives, and similar systems are critical and should > at least set boundary conditions on the discussion and options. > For others, different considerations may apply. Unless I'm > missing something. one thing that is going to turn out to be > important will be identifying the differences and which > namespaces fall into which categories and being clear about that. The only fundamental issue for me was the need of the URNs to be actionable. IMO non-functional URN (or a URN given to a resource which is not persistent) is counterproductive and should never be assigned. But we have decided that there can be URNs that will not provide any services, and that's it. In the other end of the scale, we may have namespaces with plenty of services, with frequent changes both to the existing services (additional and deprecated features) and to the list of services (new services added, old ones removed). We should design flexible means for specifying the services & service parameters available within a namespace in general, and provided by a resolver which supports the namespace in particular. Juha -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 From stpeter@stpeter.im Mon Jul 8 16:37:19 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192D521F9A26 for ; Mon, 8 Jul 2013 16:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.246 X-Spam-Level: X-Spam-Status: No, score=-102.246 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhZ286ZEKg-e for ; Mon, 8 Jul 2013 16:37:14 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E1B1221F8206 for ; Mon, 8 Jul 2013 16:37:12 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 40588413B8; Mon, 8 Jul 2013 17:38:11 -0600 (MDT) Message-ID: <51DB4D24.9050608@stpeter.im> Date: Mon, 08 Jul 2013 17:37:08 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: urn@ietf.org References: <65823B328A8C0AC3E24F5E84@localhost> <51DA76E6.6040005@helsinki.fi> In-Reply-To: <51DA76E6.6040005@helsinki.fi> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 23:37:19 -0000 Hi Juha, thank you for continuing this discussion. I think we are getting closer to a shared understanding. Comments inline, with the intent of finding text we can agree on. On 7/8/13 2:23 AM, Juha Hakala wrote: > Hello, > > > On 7.7.2013 16:58, John C Klensin wrote: >>> On 06/21/2013 10:51 AM, Barry Leiba wrote: >>>> I'll also note that I see a reasonable case for fragments >>>> actually changing what resource the URN winds up resolving >>>> to. > This would extend the scope of the URI/URN fragment well beyond what is > desirable, and also make it a lot harder to manage the identifier > assignment process. I tend to agree (and to agree with John that the word "resolution" is misleading in the context of URNs). >>>> Consider this: "urn:isbn:0-679-40758-8" would name the >>>> edition of "Don Quixote" that I have on my bookshelf. It's a >>>> big book; it has, in one cover, "Volume 1" (which subdivides >>>> into "Book I" through "Book IV") and "Volume 2" (which has >>>> "Book V" and "Book VI"). If fragments were allowed, it might >>>> be reasonable for, say, >>>> "urn:isbn:0-679-40758-8#volume.1" to get me to >>>> "http://example.com/don-quixote/vol1", and for >>>> "urn:isbn:0-679-40758-8:volume.2" to get me to >> Barry, I see where you are headed here, but I think it leads to >> madness, at least as I understand URNs. > In the real world, printed versions of Don Quijote will get different > ISBN than the digital versions. And the (separately published) volumes > of the digital Don Quijote will each get their own ISBNs. Iff there is a > one volume digital version (with a single ISBN) which is encoded so that > the beginning of each part can be indicated with a fragment, then > fragment usage will be OK - but they will not identify the parts, they > just indicate the starting position of each part within the > all-encompassing volume. > > Examples such as the one Barry has provided above illustrate why > identifier assignment has to be a managed process. There is a reason why > the ISBN community has not only the standard but also an extensive guide > book which tells how ISBNs should be used. And perhaps all this > complexity also explains why some publishers and ISBN centers > occasionally get it wrong ;-). > > One reason why we need rules and principles for usage of fragment is to > prevent people from doing things which are technically possible, but > would undermine the appropriate principles for naming documents within > that namespace. Of course there will be namespaces where anything goes. > But if we were to say that fragment (or query) is part of the NSS, it > would be necessary to revise the ISBN standard and all the other > existing standard identifiers so that the usage of URI fragments is > taken into account. I doubt anybody wants to go into that, for various > reasons (most likely many communities would just say no). The easiest > solution is to keep both fragments and queries separate from the NSS, > which a priori means that a URN and the same URN with fragment always > identify the same resource. (And also "the same URN with query", I assume?) Keeping fragments and queries separate from the NSS makes it easier for us to determine the exact text in 2141bis and 3406bis. Juha, do I understand correctly that you might suggest that we continue to define assigned URNs (or, perhaps more precisely, URIs with the urn: scheme) as "urn" ":" NID ":" NSS and then specify that fragments and queries might be strings that can be added to an assigned URN? (Perhaps the term "assigned URN" is not quite right -- suggestions are welcome.) Thus I could see something like this in 2141bis: namestring = assigned-name [ "?" query ] [ "#" fragment ] assigned-name = "urn" ":" NID ":" NSS >> It is that sort of issue which caused me to say "namespace dependent". >> If one has any delusions about fragments being part of the resolution >> process on the server, then it seems to me that standards for what is >> valid and what isn't have to be set as part of the definition of the >> namespace and that, if the namespace is itself dependent on what I >> think Juha would call a formally managed process (language supported >> by RFC 3406), by the agency that defines and interprets that process. > > Many documents have component parts which must be identified separately. > For instance, there are periodicals (identified with ISSN) plus > periodical issues, articles in those issues, and images within those > articles, all of which can be identified by e.g. national bibliography > numbers. In order to facilitate long term preservation, typical approach > is to give identifiers to everything and not use fragments within e.g. > the serial issue to indicate its component parts. This means that URN > resolution is used to access "logical fragments" such as journal > articles, but URN fragments have nothing to do with the process. > > >> The other possibility is to treat fragments as not part of the URN >> dereferencing (see below) process but as part of a discussion between >> the user who specifies a URN to a user interface and that interface, >> not the URN-resolving server. What makes this more interesting is >> that, if I correctly understand the ISBN rules, it would be possible >> for a publisher of an electronic version to assign separate ISBNs to >> the various books of Cervantes's original organization. > > Correct. If the book is published in four volumes, there should be one > ISBN for the whole book, and each volume should also get its own ISBN. > In practice, ISBN assignment is largely based on the needs of the trade: > one can buy either the entire book (all volumes) or just one volume; > therefore there is a need to separate them. > >> That would make it quite plausible to refer to "Don-Quixote-book3" by >> "URN:ISBN:0-679-NNNNN-N" and to "Don-Quixote-book4" by >> "URN:ISBN"0-679-MMMMM-M" but that obviously has nothing to do with >> fragments. If one wants to treat all printings or editions as the >> same, then URNs and fragments aren't the problem. The problem is that >> ISBNs are just not the right tool. > Yes - if somebody wants to find for instance all the editions of Don > Quixote in English, then ISTC is the identifier to use. >>> I've had a couple of ideas about this: >>> >>> 1. One is that URN resolution of a resource could return a >>> list of fragment mappings. So if you resolved >>> urn:isbn:0-679-40758-8 you might get back something that >>> included: >>> ... >>> "fragments" = { ( "volume.1" = >>> "http://example.com/don-quixote/vol1" ), >>> ( "volume.2" = >>> "http://example.com/don-quixote/vol2" ), >>> ( "book.i" = >>> "http://example.com/don-quixote/vol1#bk1" ), >>> ( "book.ii" = >>> "http://example.com/don-quixote/vol1#bk2" ), >>> ( "book.iii" = >>> "http://example.com/don-quixote/vol1#bk3" ), >>> ( "book.iv" = >>> "http://example.com/don-quixote/vol1#bk4" ), >>> ( "book.v" = >>> "http://example.com/don-quixote/vol2#bk5" ), >>> ( "book.vi" = >>> "http://example.com/don-quixote/vol2#bk6" ) } >>> ... >> Arggh. I think this ignores what ISBNs actually are. It is the >> collision between our engineering speculations and theories and >> the reality of well-established identifier systems that >> represent consensus and extensive practices with their own rules >> that gets us into trouble here. > + 1 > > (This is just an example.) According to the ISBN assignment rules, there > should be an ISBN for e.g. an English translation of Don Quixote > published by Victor Gollancz in EPUB 3 (all six volumes), and in > addition each volume should have its own ISBN. If the service the user > wants is URN to URLs, then the URN:ISBN of the whole thing should > resolve to a list of six URLs. On the other hand, URN:ISBN of a single > volume will resolve to single URL (provided that there is only one > location from which the book can be retrieved; often there are many). > > Within the technical limitations of the EPUB version, anyone should be > able to cite / refer to the chapters etc. within the volumes using URI > fragments. But these fragments do not identify chapters. > > In some circumstances it might be useful to have a URN resolution > service (available via a query parameter) which harvests the structure > of the document (chapters, parts, names of articles within a book which > consists of articles). But since the encoding of the documents can be > non-informative, it is a better idea to check descriptive metadata to > find out about the resource. Table of contents is probably much more > readable than any fragment listing. Juha, I admit that I still don't understand how such a dereferencing (or, better, metadata-retrieval) service would work. How would a client of this service discover the address and API of the service? In today's web, I could see us defining a well-known URI (RFC 5785) at which one could send a request (passing the assigned URN as a parameter) and then receiving in response a metadata file in a format like XML or JSON. But IMHO that doesn't necessitate adding query strings to assigned URNs. In any case, if people feel that they need to add query strings onto the end of assigned URNs (or are already doing that in practice) then I now think it is acceptable to define a way to do that, as long as we say that it is the responsibility of each namespace that allows query strings (and fragment identifiers) to carefully define what those mean in the context of that namespace. >>> 2. Another idea is that you might need separate mechanisms to >>> permit identifiers to refer to HTML-style fragments, than >>> those used to refer to persistent fragments. For consistency >>> with other URIs that refer to HTML-style fragments I'd >>> recommend continuing to use the '#' notation for these. But >>> using the syntax I proposed, you could define a /region=xxx >>> option (call it something different than fragment to minimize >>> the potential for confusion). And I'm thinking that all such >>> options should be input to any resolution service (so the >>> client wouldn't have to know which options applied at which >>> layer), so the resolution service would see that the client >>> wanted region "book.iv" and could return the right URL (if not >>> the whole list of regions). >> This gives me a nasty headache. But, at least the way I read >> 3896, there is nothing that requires the semantics of fragments >> to be constant across URI types (or even across resources). > My preference is to get started with HTML-style fragments using the > #-notation, and to provide basic guidelines for development of namespace > specific solutions. This is what Alfred Hoenes and myself were already > doing in the previous versions of URNbis I-Ds. > > There are a lot of projects etc. out there which are hoping to identify > component parts of resources. These component parts may be for instance > concepts in a corpus database, or variables within research data sets. > The 1000 USD question is whether it is possible / advisable to use > generic URN syntax tools for this. I do not think so. > > Given the diversity of the URN namespaces, it is not likely that we can > find a generic syntax that would work for everyone. But this is not even > necessary. What we need to say is that each namespace may have its own > practices for identification of component parts of resources, as long as > they do not conflict with URI syntax and there are resolution services > which can deal with the resulting URNs. > > For identification of component parts of resources ("logical fragments") > one should never use URI fragments, but identifiers created on the > basis of namespace specific practices which must be supplied in the > namespace registration request. For the ISBN namespace the principle is > carved in stone in the standard: one can assign ISBN for e.g. a chapter > of a book (like chapter 1 of Don Quixote, vol. 1) if the chapter is > available as a separate item. For NBN, each organization assigning > identifiers has the freedom to decide what to do within its own > sub-namespace. Juha, I see a tension between your statements and I am hoping you can clarify something. As I read your email, I think you are saying that you would like to use fragment identifiers with '#' notation. However, then you say that identification of component parts of resources should never use URI fragments (i.e., never use '#' notation). It would help me if you could explain when you think URI fragment syntax is appropriate and when it is not. What exactly are "logical fragments"? Are there other kinds of fragments (e.g., "physical fragments")? Your statement "if the chapter is available as a separate item" seems to indicate that that the item might be physically separate and therefore that URN-assigning entity might decide to allow '#' notation to identify such items (it's true that ISBN does not allow this, but that's a matter for the ISBN namespace -- the NBN namespace might allow that or might allow sub-namespaces to come up with their own syntax for fragments, using '.' instead of '#' or whatever). Do I understand you correctly? >>> In summary, I do see the potential that some fragment-like >>> construct that were resolved as part of the URN could be >>> useful. I just don't think it's a good idea to prevent users >>> from addressing individual HTML-style fragments of a document >>> in conjunction with URNs. And I think it would be confusing >>> if we repurposed '#' to mean something subtly different for >>> URNs than for other URIs. > + 1 to all of the above, except that I think that the best we can have > is namespace specific fragment-like constructs. By "namespace specific fragment-like constructs" do you mean "each namespace is allowed to define its own constructs for identifying fragment-like things, as long as the syntax does not involve the use of '#' as the denotation of the start of the fragment-like thing in the name"? Or do you think that '#' is allowed as well? Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Jul 8 20:29:34 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623A611E8113 for ; Mon, 8 Jul 2013 20:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.112 X-Spam-Level: X-Spam-Status: No, score=-102.112 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohhgdmorh8rK for ; Mon, 8 Jul 2013 20:29:29 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 362A611E8110 for ; Mon, 8 Jul 2013 20:29:28 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 19B2E413BD; Mon, 8 Jul 2013 21:30:29 -0600 (MDT) Message-ID: <51DB8396.7020802@stpeter.im> Date: Mon, 08 Jul 2013 21:29:26 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Juha Hakala References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <4A9225387F6E4CCB5BB1A018@JcK-HP8200.jck.com> <51BC8D66.9050000@network-heretics.com> <7ED5CCF8F4C22A4918928866@JcK-HP8200.jck.com> <51D6C1B0.7010004@helsinki.fi> <40BA98D4D3399F1F1597B425@[192.168.1.128]> <51DA956D.9070008@helsinki.fi> In-Reply-To: <51DA956D.9070008@helsinki.fi> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 03:29:34 -0000 Hi Juha, On 7/8/13 4:33 AM, Juha Hakala wrote: > Hello, > > On 6.7.2013 5:05, John C Klensin wrote: >> Juha, >> >> This analysis is very helpful, at least for me. It feels like >> we are on our way to a discussion, rather than the staking out >> of positions that I think has sometimes characterized this WG. > When the URN system were developed there were fewer issues between IETF > and the communities using identifiers such as libraries. It looks like > after a decade of using URNs the gap between theory and practice seems > to have become wider. It is possible that this time the user communities > have specific requirements, and finding an acceptable way of > implementing them has been hard. Some of the issues we have faced have > been fully justified, but sometimes theoretical discussions about the > principles of identification on this list have established problems that > are not really there. So it seems. But in theory the IETF believes in running code, so the use of URNs over the last 10+ years ought to count for something. :-) > There are quite a few persistent identifiers (PIDs) in use. Among the > three most popular ones - Handle, DOI and URN - only URN is under IETF's > wing. All of these identifiers are older than RFC 3986 and do not > support either query or fragment. If URNbis succeeds in adding them to > URN syntax, Handle and DOI may follow - which would not be a bad thing. >> I personally would have preferred a URN syntax that was >> unmistakably not a member of the URI family, but I lost that >> argument and probably for good reasons. And it was lost, and >> the URI concept invented, in the 90s, not in 2005. > I would like to see the arguments in favour of one URI to rule them all. >>>> Nonetheless, I think that getting this right first and then >>>> seeing what, if necessary has to be done to align things with >>>> 3968 (or vice versa) is a reasonable strategy. >>> Agreed. >> In particular, what is really important about 3986, at least >> IMO, is the syntax and the rules that bear directly on it. More >> philosophical discussions about the relationships among >> identifier types ought to be possible to clarify without doing >> any significant harm. > I have assumed for quite a while now that we cannot divert from URI > generic syntax. Such diversions are possible when using PIDs; there is a > project using Handles which chose to use "@" as the fragment separator. > But resolving such URIs correctly requires special software (in the case > above, a tuned Handle resolver) and in the long term breaking URI syntax > (or making private extensions to Handle syntax) is likely to be risky. > Unfortunately persistent identifiers are for long term... >> >>> It is important to find a compromise which is acceptable both >>> for IETF (from RFC 3986 point of view) and for communities who >>> are using bibliographic and other identifiers and wish to make >>> them actionable in the Internet. If this WG does not find a >>> solution, then groups using persistent identifiers (Handles, >>> DOIs, URNs and ARKs) will develop their own solutions. This is >>> already happening, and some of the solutions I've seen are >>> completely incompatible with the URI syntax. And even if the >>> requirements of RFC 3986 are followed, interoperability may be >>> in danger. >> I would prefer to avoid the concept of "compromise". I think >> there is a reasonable solution lurking out there and that your >> note contributes to finding it. If that is not the case, we >> have gotten URNs seriously wrong, wrong enough that we need to >> do some rather fundemantAal rethinking that might even lead to >> deprecating them in favor of a different model. I don't believe >> that is likely to be necessary, but we shouldn't dismiss it out >> of hand. > Please keep in mind that tens of millions of URNs have been assigned > already. They cannot be deprecated, and we cannot make any fundamental > changes which would render old and new URNs non-interoperable. What we > can do is to add new functionality, such as fragments and queries, and > make it easier for people to use URNs by for instance changing the way > in which services are registered. Might I ask you to explain what you mean by the registration of services here? Are you referring to registration of namespace identifiers as in RFC 3406, or something else? >>> It is not stupid to add a fragment if one can safely assume >>> that the identified resource will not change. With URLs there >>> is absolutely no guarantee of that. Within the URN system, >>> there are namespaces such as URN:ISBN where fragments will >>> work as long as the user has a tool with which the resource >>> can be used. >> I think we need to accept two things, both of which should be >> obvious. (1) URNs and URLs have different semantics (not just >> permanence properties. As a result, the semantics of, >> restriction on, and expectations of, fragment identifiers are >> going to be different, even if the basic syntax framework is the >> same. (2) Hi John, what was #2? ;-) > IMO, fragment is just a fragment, no matter whether it is attached to > URL or to URN. Even when added to a URN it does not identify anything. Pendantic point: if that is true, then why do we call it a fragment identifier component? Sure it must identify the "indicated location within the resource", as you say... > Same functionality is expected; the viewing application should take the > user to the indicated location within the resource. From functional > point of view the main difference is that URL + fragment combination is > much more fragile than URN + fragment. Document available in address X > may change any time, but document with URN should not change, although > it may be moved to a different location. Agreed. > If and when we decide to use query, then URN will have a set of services > and service parameters that have been specified as queries. For URLs > nothing will be carved in stone like this. Juha, do you mean that we would define stable queries that apply to all URNs (or all URNs within a namespace) and that service providers would not be encouraged or allowed to define their own non-standard queries? >>> OK. But for practical reasons we should make clear that >>> fragment is not part of the NSS and therefore does not >>> identify anything. The fragment indicates just a location >>> within the identified resource and is used by viewing >>> applications once the entire resource has been retrieved. >> Works for me. Perhaps the "once...has been retrieved" >> requirement is part of the rational boundary between (using a >> book as an example) "URNs points to book, fragment marks chapter >> beginning" and "URNs point to chapters with multiple URNs per >> book and the book considered as a collection of chapters rather >> than an object". > OK. Seems sensible. >> I think what is most >> important is that either fragments are unambiguously part of the >> URN (for matching and retrieval purposes) or they are not. > Yes, we cannot allow both options. In practice, the only feasible option > is that URI fragments are not part of the NSS, which means that they may > be added to the URN, but from the point of resolution and semantic > equivalence the URN is still the same. Agreed. > For those who need to identify component parts ("fragments") of > resources, the URN syntax should provide a means of doing that in a > namespace specific manner. Here again I need to ask something I queried about in another message: do you mean that we would *not* allow fragments using URI '#' syntax but instead would leave the syntax up to the namespace (e.g., one could use '.' or some other character as the delimiter for fragments within a given namespace)? >> So there will be URNs which are associated with the resource, but >> there will also be many other kinds of URNs, and linking all of them >> together should help us to provide all users what they want, now and >> in the (very) distant future. >> That is all completely reasonable and understandable, modulo the >> concerns about undifferentiated layers of references above. >> Perhaps that is not a problem, but it seems to me to have the >> potential for a lot of complexity, referencing loops, etc. > Long term preservation based on migration will involve a lot of > complexity. Over time there will be multiple versions of every resource > that can be migrated, and a lot of supporting administrative metadata > which describes the differences between successive versions of the > document. > > In order to make sense of all this, librarians have developed models > such as FRBR (Functional Requirements for Bibliographic Records) > > http://en.wikipedia.org/wiki/Functional_Requirements_for_Bibliographic_Records > > > which describe how the different components of the system relate to one > another. FRBR does not prevent the possibility of referencing loop, but > a proper implementation of the model should not lead the users astray. > On the other hand, making a complex model like FRBR work, we need > persistent links between e.g. work and manifestation records. > Experiments which have used database internal URLs have proven that. >> >> I also wonder a bit about your "managed" assertion. I think it >> is safe to assume that some namespaces will be a lot more >> managed than others and that many of them will face the >> perennial problem with groups of Internet identifiers: the >> inability to compel use of the management or registration >> process if someone wants to go their own way. > Probably the main difference between Handle and DOI is that DOIs are > better managed. There has been problems with DOI (a publisher purchasing > a journal, and then changing the DOIs of all the articles) but they are > less common than with Handles. > > With URN there will be a lot of differences between namespaces. There is > no management at all with UUID, and there may be namespaces where no > resolution is provided, in which case any centralised management is a > priori not necessary. > > Poor service level (which will look like low reliability to the users) > in some URN namespaces may undermine the value of the entire URN system. I'm not so sure about that, because I don't think that anyone really considers or uses the URN system as a whole. People in publishing use ISBN and ISSN and so on. Libraries use those and NBN. Folks in academia might use SCHAC (RFC 6338). Developers and operators in the mobile telephony space might use OMA and 3GPP (RFCs 4358 and 5279). Financial applications might use SWIFT (RFC 3615). And so on. > Therefore I regret the fact that it has been so easy to register URN > namespaces. At least there should be an organization responsible of the > namespace, in case there are questions about it. As far as I can see that's true of almost all formal namespaces (the main exception I see is UUID). >> URN should take into account well established identifiers and >> user groups which have resources to preserve digital resources >> for long term. A national library using urn:isbn is not a >> corner case but a key user group with fairly well specified >> needs - although I may not be able to express them clearly >> enough. >> yes, but I think you and others are going to have to continue to >> educate the rest of us if URNs are going to succeed. I >> appreciate your patience and willingness to do so. > A particular strength of the URN system compared with other persistent > identifiers is that it is fully compliant with existing bibliographic > and other identifier systems. URN does not rival the old identifiers by > specifying a new identifier system (unlike DOI, Handle and ARK); > instead, with URN namespaces all the rules can be aligned according to > the specific needs of the identifier community in question. ISBN > embedded into URN can be extracted and parsed easily; ISBN embedded into > DOI needs a lot more work (since part of ISBN goes into DOI prefix, and > other part into DOI suffix, and it is not obvious that the DOI string is > an ISBN). >> At the same time, I think all of us need to understand that not >> all URNs (and namespaces) are the same and need to be treated >> the same way. For some, the experience and constraints of >> libraries, archives, and similar systems are critical and should >> at least set boundary conditions on the discussion and options. >> For others, different considerations may apply. Unless I'm >> missing something. one thing that is going to turn out to be >> important will be identifying the differences and which >> namespaces fall into which categories and being clear about that. > The only fundamental issue for me was the need of the URNs to be > actionable. IMO non-functional URN (or a URN given to a resource which > is not persistent) is counterproductive and should never be assigned. > But we have decided that there can be URNs that will not provide any > services, and that's it. Actually there are lots of "non-functional", "non-dereferencable" namespaces. Maybe the organizations managing those mint far fewer URNs, but I don't think it's productive to say that URNs that don't provide services (e.g., you can't dereference them to retrieve metadata) are counterproductive. As John says, they simply fall into a different category. We could have a discussion about whether it might have made sense to to define something other than URNs for those identifiers, but that's water under the bridge now and IMHO it's best to try to accomodate all the existing uses as best we can. > In the other end of the scale, we may have namespaces with plenty of > services, with frequent changes both to the existing services > (additional and deprecated features) and to the list of services (new > services added, old ones removed). We should design flexible means for > specifying the services & service parameters available within a > namespace in general, and provided by a resolver which supports the > namespace in particular. Mostly I see these services as a matter for specifications other than 2141bis. However, I now agree that we need to at least allow queries and fragments in the syntax (but not within the NSS), and that's all I care about for 2141bis. I'll leave documentation of services and URN resolution to someone braver than I. :-) Peter -- Peter Saint-Andre https://stpeter.im/ From juha.hakala@helsinki.fi Mon Jul 8 22:52:23 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6297921F9F1B for ; Mon, 8 Jul 2013 22:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.531 X-Spam-Level: X-Spam-Status: No, score=-5.531 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9UXzEsXSKQs for ; Mon, 8 Jul 2013 22:52:17 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1B40E21F9DF5 for ; Mon, 8 Jul 2013 22:52:15 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r695qB1C003020 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 9 Jul 2013 08:52:12 +0300 Message-ID: <51DBA50A.1060701@helsinki.fi> Date: Tue, 09 Jul 2013 08:52:10 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <4A9225387F6E4CCB5BB1A018@JcK-HP8200.jck.com> <51BC8D66.9050000@network-heretics.com> <7ED5CCF8F4C22A4918928866@JcK-HP8200.jck.com> <51D6C1B0.7010004@helsinki.fi> <40BA98D4D3399F1F1597B425@[192.168.1.128]> <51DA956D.9070008@helsinki.fi> <51DB8396.7020802@stpeter.im> In-Reply-To: <51DB8396.7020802@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 05:52:23 -0000 Hello Peter, On 9.7.2013 6:29, Peter Saint-Andre wrote: > Hi Juha, > > >> Please keep in mind that tens of millions of URNs have been assigned >> already. They cannot be deprecated, and we cannot make any fundamental >> changes which would render old and new URNs non-interoperable. What we >> can do is to add new functionality, such as fragments and queries, and >> make it easier for people to use URNs by for instance changing the way >> in which services are registered. > Might I ask you to explain what you mean by the registration of services > here? Are you referring to registration of namespace identifiers as in > RFC 3406, or something else? I mean the registration of new / altered resolution services. At the moment we have (experimental) RFC 2483 which describes a fixed set of resolution services necessary for URN resolution. These services are based on the technical infrastructure of late 90's. Based on the experiences the National Library of Finland has got from maintaining both a national URN resolution service and a number of digital library applications, there are a few improvements needed: 1. RFC 2483 assumes that the resolution services do not need parameters. For instance, if a user requests metadata about the resource, one size fits all - the (non-existent) URC will do. If only it were that simple: in practice, a user may need descriptive metadata which can be available in many formats (MARC 21, Dublin Core, EAD, LIDO and so on) or administrative metadata which has its own formats. So instead of having just two services (I2C, or URI to URC, and I2Cs) we shall need either one service for each metadata format which would be cumbersome, or enriched I2C service which allows the user to specify either the format or the metadata type (descriptive or administrative; the latter consists of technical, preservation and rights metadata) wanted. 2. Specifying the services in an RFC is based on the assumption that the set of URI resolution services is relatively stable and does not require frequent updates. It is not likely that is the case, since resolution services depend on a technical infrastructure which has been changing fast. Emerging services, such as digital archives, will enable us to provide new kinds of services, which from URI resolution point of view may be either entirely new services or additional parameters to existing ones. Some examples of services that have emerged since RFC 2483 was written (assuming, among other things, that there is a fully functional digital archive application which interacts with the URN resolver): A. On the basis of the URN of work X, show me all its manifestations (PDF, OOXML, EPUB 3 etc.) B. On the basis of the URN of work X, show me all the other works related to it C. Based on the URN of manifestation X, show me all the other manifestations of the same work D. On the basis of preservation metadata, show me the differences (resulting from successive migrations) between the manifestations of work X E. On the basis of technical metadata, show me the software and hardware requirements of using manifestation X F. On the basis of rights metadata, show me if I can access copy Y of manifestation X 3. RFC 2483 does not enable specification of formal, informal and experimental resolution services. Such division might be useful (see below). Alfred Hoenes and myself concluded that what we need is an IANA URN resolution service registry (similar to the URN namespace registry), and an RFC which specifies how such a registry is to be maintained. I believe that the maintenance of the service registry is less challenging than maintenance of the namespace registry. For each new URN namespace, IANA / IETF should estimate if the namespace is managed well enough and whether the identifier system meets the requirements. For resolution service / service parameter no such scrutiny is needed. But it is important to maintain a central registry if them, so as to guarantee that the users of the URNs do not re-invent the wheel. IANA may decide that maintaining this registry is not within its scope. In that case URNbis should find another volunteer. IMO it is not possible to write and RFC which specifies URN resolution service registry and its maintenance procedure without telling who runs the show. >> IMO, fragment is just a fragment, no matter whether it is attached to >> URL or to URN. Even when added to a URN it does not identify anything. > Pendantic point: if that is true, then why do we call it a fragment > identifier component? Sure it must identify the "indicated location > within the resource", as you say... I do not call it fragment identifier; you do. Let's use an analogy. Every house in Finland has an address. But Finnish Ordnance Survey does not use the address as an identifier for the house; they have an entirely different system for that. The names of cities and streets can change, so address is not persistent enough to serve as an identifier. If I want to identify an article within a journal issue, I'd never use the identifier of the issue and a fragment which shows where the article begins within the issue. The same article may be / will be published in many other places, independently of the original context (the journal issue). Any identifier which assumes that the issue is there might soon become a real pain in the neck. It is much better idea to have separate identifier for the article, although in order to access it one may use also the URN of the issue plus fragment. When the journal and the issue are migrated into new file format, new identifiers will of course be assigned. A link between the old and new manifestation is established in metadata, with the description of the differences between the two manifestations in preservation metadata. >> If and when we decide to use query, then URN will have a set of services >> and service parameters that have been specified as queries. For URLs >> nothing will be carved in stone like this. > Juha, do you mean that we would define stable queries that apply to all > URNs (or all URNs within a namespace) and that service providers would > not be encouraged or allowed to define their own non-standard queries? I would definitely not encourage the service providers to define non-standard queries, since that would reduce interoperability between URN resolvers. If I need to get e.g. technical metadata for a document held in the digital archive of the National Library of Norway, it would be really annoying if my client app should use different service + service parameter combination than our resolver in Finland uses. But it should be OK to allow service providers to specify experimental queries and query parameters for internal usage, with an assumption that such things may become formal services / service parameters in the future. > >> For those who need to identify component parts ("fragments") of >> resources, the URN syntax should provide a means of doing that in a >> namespace specific manner. > Here again I need to ask something I queried about in another message: > do you mean that we would *not* allow fragments using URI '#' syntax but > instead would leave the syntax up to the namespace (e.g., one could use > '.' or some other character as the delimiter for fragments within a > given namespace)? Yes. In URNs, fragment using the URI "#" syntax should not have any meaning beyond what RFC 3986 assigns for it. Any diversion might cause us problems now or in the (more or less distant) future. Namespace specific solutions for identifying fragments (or component parts of documents or whatever the fragment is called) may use basically any means for fragment identification, except the URI generic syntax. Resolvers which cope with the identifiers within that namespace must know how treat these URNs. Most often the process will be straightforward since identifiers for component parts are the same as the identifiers for host documents. > >> The only fundamental issue for me was the need of the URNs to be >> actionable. IMO non-functional URN (or a URN given to a resource which >> is not persistent) is counterproductive and should never be assigned. >> But we have decided that there can be URNs that will not provide any >> services, and that's it. > Actually there are lots of "non-functional", "non-dereferencable" > namespaces. Maybe the organizations managing those mint far fewer URNs, > but I don't think it's productive to say that URNs that don't provide > services (e.g., you can't dereference them to retrieve metadata) are > counterproductive. As John says, they simply fall into a different > category. We could have a discussion about whether it might have made > sense to to define something other than URNs for those identifiers, but > that's water under the bridge now and IMHO it's best to try to > accomodate all the existing uses as best we can. OK. >> In the other end of the scale, we may have namespaces with plenty of >> services, with frequent changes both to the existing services >> (additional and deprecated features) and to the list of services (new >> services added, old ones removed). We should design flexible means for >> specifying the services & service parameters available within a >> namespace in general, and provided by a resolver which supports the >> namespace in particular. > Mostly I see these services as a matter for specifications other than > 2141bis. However, I now agree that we need to at least allow queries and > fragments in the syntax (but not within the NSS), and that's all I care > about for 2141bis. I'll leave documentation of services and URN > resolution to someone braver than I. :-) Great; allowing both fragment and query and thus aligning URNs with the URI syntax as specified in RFC 3986 is at least a very good start :-). And Alfred Hoenes has already written an I-D which outlines the IANA registry for URN resolution services, so there is no need to start from scratch. Juha > > Peter > -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 From juha.hakala@helsinki.fi Tue Jul 9 01:14:53 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE6F21F9F14 for ; Tue, 9 Jul 2013 01:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.976 X-Spam-Level: X-Spam-Status: No, score=-4.976 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NteqaG7E9zEK for ; Tue, 9 Jul 2013 01:14:47 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 99EDB21F9F0E for ; Tue, 9 Jul 2013 01:14:43 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r698Eep3016382 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Tue, 9 Jul 2013 11:14:41 +0300 Message-ID: <51DBC670.5050703@helsinki.fi> Date: Tue, 09 Jul 2013 11:14:40 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: urn@ietf.org References: <65823B328A8C0AC3E24F5E84@localhost> <51DA76E6.6040005@helsinki.fi> <51DB4D24.9050608@stpeter.im> In-Reply-To: <51DB4D24.9050608@stpeter.im> Content-Type: multipart/alternative; boundary="------------020800040001070200090308" Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 08:14:53 -0000 This is a multi-part message in MIME format. --------------020800040001070200090308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Peter, On 9.7.2013 2:37, Peter Saint-Andre wrote: > Hi Juha, thank you for continuing this discussion. I think we are > getting closer to a shared understanding. I hope so; if we manage to agree on things then I may avoid writing national extensions to the IETF RFCs ;-). > > Comments inline, with the intent of finding text we can agree on. > > On 7/8/13 2:23 AM, Juha Hakala wrote: > > The easiest > solution is to keep both fragments and queries separate from the NSS, > which a priori means that a URN and the same URN with fragment always > identify the same resource. > (And also "the same URN with query", I assume?) Yes. But while clients should not even send the fragment to servers when they retrieve documents, queries will be evaluated by (in this case) URN resolvers. In a complex environment resolvers must have quite a lot of intelligence ot cope with the situation; for instance, what the user wants may best be met by descriptive metadata from the national bibliography, the document itself from the institutional repository, or the oldest possible manifestation of the work from the digital archive. > > Keeping fragments and queries separate from the NSS makes it easier for > us to determine the exact text in 2141bis and 3406bis. Good. > Juha, do I understand correctly that you might suggest that we > continue to define assigned URNs (or, perhaps more precisely, URIs > with the urn: scheme) as "urn" ":" NID ":" NSS and then specify that > fragments and queries might be strings that can be added to an > assigned URN? (Perhaps the term "assigned URN" is not quite right -- > suggestions are welcome.) Thus I could see something like this in > 2141bis: namestring = assigned-name [ "?" query ] [ "#" fragment ] > assigned-name = "urn" ":" NID ":" NSS Exactly. And it might not do any harm if we make it clear that while identifier assignment can be a managed process in some namespaces, once the URN has been assigned, anyone - human or a machine - can add a fragment or a query to it. >> In some circumstances it might be useful to have a URN resolution >> service (available via a query parameter) which harvests the structure >> of the document (chapters, parts, names of articles within a book which >> consists of articles). But since the encoding of the documents can be >> non-informative, it is a better idea to check descriptive metadata to >> find out about the resource. Table of contents is probably much more >> readable than any fragment listing. > Juha, I admit that I still don't understand how such a dereferencing > (or, better, metadata-retrieval) service would work. How would a client > of this service discover the address and API of the service? Clients would not need to know anything about it. Currently URN resolution services have relatively simple mapping tables which may simply say that document with this URN is available from this / these location / locations. These resolution services must become more versatile with the digital library applications. In the future the resolver has to know (for instance) where to obtain descriptive metadata about resources, the resources themselves, or past versions of these resources. These services may be available via 1-n applications and 1-n APIs. Specifying them is beyond the scope of URNbis. What we need is a set of URN standards which does not become a bottleneck when there is a need to specify new resolution services. It looks like URNbis is heading to the right direction. > In today's > web, I could see us defining a well-known URI (RFC 5785) at which one > could send a request (passing the assigned URN as a parameter) and then > receiving in response a metadata file in a format like XML or JSON. But > IMHO that doesn't necessitate adding query strings to assigned URNs. In > any case, if people feel that they need to add query strings onto the > end of assigned URNs (or are already doing that in practice) then I now > think it is acceptable to define a way to do that, as long as we say > that it is the responsibility of each namespace that allows query > strings (and fragment identifiers) to carefully define what those mean > in the context of that namespace. I'll take a look at RFC 5785. > >> >> For identification of component parts of resources ("logical fragments") >> one should never use URI fragments, but identifiers created on the >> basis of namespace specific practices which must be supplied in the >> namespace registration request. For the ISBN namespace the principle is >> carved in stone in the standard: one can assign ISBN for e.g. a chapter >> of a book (like chapter 1 of Don Quixote, vol. 1) if the chapter is >> available as a separate item. For NBN, each organization assigning >> identifiers has the freedom to decide what to do within its own >> sub-namespace. > Juha, I see a tension between your statements and I am hoping you can > clarify something. > > As I read your email, I think you are saying that you would like to use > fragment identifiers with '#' notation. Yes, we should allow the use of URI fragment for indicating a location within a resource which has already been identified by a URN. > However, then you say that > identification of component parts of resources should never use URI > fragments (i.e., never use '#' notation). The point being that URI fragments must not identify anything and therefore they must not be a part of the NSS. > It would help me if you could > explain when you think URI fragment syntax is appropriate and when it is > not. What exactly are "logical fragments"? Are there other kinds of > fragments (e.g., "physical fragments")? Yes. As I see it, URI fragment can be applied to physical fragments in a document that has a URN. For instance, if a resource is a digitized journal issue with a single URN:NBN, it is possible to cite an article within the issue by giving the URN and fragment which takes the users to the beginning of the article. Depending on the physical encoding of the document, URI fragment can be used to pinpoint any location within the article. If URI fragments do identify subordinate resources (as stated for instance in http://en.wikipedia.org/wiki/Fragment_identifier) we would need some guidelines on what these resources actually are. Having a lot of experience on the use of bibliographic identifiers, I find for instance this statement from the Wikipedia page rather interesting: > The following example identifies lines 11 through 20 of a text document: > > * |http://example.com/document.txt#line=10,20| > What happens when the content on lines 11-20 (why not 10-20) changes? What is identified after the author cuts the document so that it contains only 9 lines? What happens if somebody adds a few lines to the beginning of the text? What if document.txt becomes document.xxx and the relevant content is on different lines or the fragment does not work any more? These, and many other problems disappear if we decide that the URL above does not identify anything, and the fragment just indicates a location within a resource which at least used to be available in the network address given. Logical fragments such as journal articles or book chapters may or may not be represented in the physical encoding of the resource. Be that as it may, URI fragments should not be used to identify them. For instance, in order to facilitate long term preservation and access the National Library of Finland assigns URN:NBNs to e.g. both journal articles and images within those articles. This will make it easier to migrate these resources to new file formats. If we were using just fragments for identifying articles within a journal issue, we might be in trouble if the new file format (resulting from migration) would not support the use of URI fragments. > Your statement "if the chapter > is available as a separate item" seems to indicate that that the item > might be physically separate and therefore that URN-assigning entity > might decide to allow '#' notation to identify such items (it's true > that ISBN does not allow this, but that's a matter for the ISBN > namespace -- the NBN namespace might allow that or might allow > sub-namespaces to come up with their own syntax for fragments, using '.' > instead of '#' or whatever). > > Do I understand you correctly? Not exactly. It is possible to give an ISBN to chapter 1 of volume 1 of Don Quijote, if the chapter is for sale as an e-book. Once the book has URN:ISBN, anybody can use URI fragment to provide access to any location within the chapter. RFC 3986 would say that these users have identified subordinate parts within the chapter. A lot of hairy problems regarding e.g. the definition of subordinate parts can be avoided if we just say that in theory it is possible to specify any location within the document with a fragment, provided that has been identified by the URN. As I see it, the mess we end up with when we assume that URI fragment actually identifies something is just another example why it is a bad idea to mix location (in this case not in the Web, but within a single document) and identification. > >>>> In summary, I do see the potential that some fragment-like >>>> construct that were resolved as part of the URN could be >>>> useful. I just don't think it's a good idea to prevent users >>>> from addressing individual HTML-style fragments of a document >>>> in conjunction with URNs. And I think it would be confusing >>>> if we repurposed '#' to mean something subtly different for >>>> URNs than for other URIs. >> + 1 to all of the above, except that I think that the best we can have >> is namespace specific fragment-like constructs. > By "namespace specific fragment-like constructs" do you mean "each > namespace is allowed to define its own constructs for identifying > fragment-like things, as long as the syntax does not involve the use of > '#' as the denotation of the start of the fragment-like thing in the > name"? Or do you think that '#' is allowed as well? No, we should not allow "#" for namespace specific constructs. Juha > > Peter > -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 --------------020800040001070200090308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Peter,

On 9.7.2013 2:37, Peter Saint-Andre wrote:
Hi Juha, thank you for continuing this discussion. I think we are
getting closer to a shared understanding.
I hope so; if we manage to agree on things then I may avoid writing national extensions to the IETF RFCs ;-). 

Comments inline, with the intent of finding text we can agree on.

On 7/8/13 2:23 AM, Juha Hakala wrote:


 The easiest
solution is to keep both fragments and queries separate from the NSS,
which a priori means that a URN and the same URN with fragment always
identify the same resource.

(And also "the same URN with query", I assume?)
Yes. But while clients should not even send the fragment to servers when they retrieve documents, queries will be evaluated by (in this case) URN resolvers. In a complex environment resolvers must have quite a lot of intelligence ot cope with the situation; for instance, what the user wants may best be met by descriptive metadata from the national bibliography, the document itself from the institutional repository, or the oldest possible manifestation of the work from the digital archive.  

Keeping fragments and queries separate from the NSS makes it easier for
us to determine the exact text in 2141bis and 3406bis.
Good.

Juha, do I understand correctly that you might suggest that we continue to define assigned URNs (or, perhaps more precisely, URIs with the urn: scheme) as "urn" ":" NID ":" NSS and then specify that fragments and queries might be strings that can be added to an assigned URN? (Perhaps the term "assigned URN" is not quite right -- suggestions are welcome.) Thus I could see something like this in 2141bis: namestring = assigned-name [ "?" query ] [ "#" fragment ] assigned-name = "urn" ":" NID ":" NSS

Exactly. And it might not do any harm if we make it clear that while identifier assignment can be a managed process in some namespaces, once the URN has been assigned, anyone - human or a machine - can add a fragment or a query to it.  

In some circumstances it might be useful to have a URN resolution
service (available via a query parameter) which harvests the structure
of the document (chapters, parts, names of articles within a book which
consists of articles). But since the encoding of the documents can be
non-informative, it is a better idea to check descriptive metadata to
find out about the resource. Table of contents is probably much more
readable than any fragment listing.

Juha, I admit that I still don't understand how such a dereferencing
(or, better, metadata-retrieval) service would work. How would a client
of this service discover the address and API of the service?
Clients would not need to know anything about it.

Currently URN resolution services have relatively simple mapping tables which may simply say that document with this URN is available from this / these location / locations. These resolution services must become more versatile with the digital library applications. In the future the resolver has to know (for instance) where to obtain descriptive metadata about resources, the resources themselves, or past versions of these resources. These services may be available via 1-n applications and 1-n APIs. Specifying them is beyond the scope of URNbis.

What we need is a set of URN standards which does not become a bottleneck when there is a need to specify new resolution services. It looks like URNbis is heading to the right direction. 
In today's
web, I could see us defining a well-known URI (RFC 5785) at which one
could send a request (passing the assigned URN as a parameter) and then
receiving in response a metadata file in a format like XML or JSON. But
IMHO that doesn't necessitate adding query strings to assigned URNs. In
any case, if people feel that they need to add query strings onto the
end of assigned URNs (or are already doing that in practice) then I now
think it is acceptable to define a way to do that, as long as we say
that it is the responsibility of each namespace that allows query
strings (and fragment identifiers) to carefully define what those mean
in the context of that namespace.
I'll take a look at RFC 5785.  



For identification of component parts of resources ("logical fragments")
one should never use  URI fragments, but identifiers created on the
basis of namespace specific practices which must be supplied in the
namespace registration request. For the ISBN namespace the principle is
carved in stone in the standard: one can assign ISBN for e.g. a chapter
of a book (like chapter 1 of Don Quixote, vol. 1) if the chapter is
available as a separate item. For NBN, each organization assigning
identifiers has the freedom to decide what to do within its own
sub-namespace.

Juha, I see a tension between your statements and I am hoping you can
clarify something.

As I read your email, I think you are saying that you would like to use
fragment identifiers with '#' notation.
Yes, we should allow the use of URI fragment for indicating a location within a resource which has already been identified by a URN. 
However, then you say that
identification of component parts of resources should never use URI
fragments (i.e., never use '#' notation).
The point being that URI fragments must not identify anything and therefore they must not be a part of the NSS. 

It would help me if you could
explain when you think URI fragment syntax is appropriate and when it is
not. What exactly are "logical fragments"? Are there other kinds of
fragments (e.g., "physical fragments")?
Yes.  As I see it, URI fragment can be applied to physical fragments in a document that has a URN. For instance, if a resource is a digitized journal issue with a single URN:NBN, it is possible to cite an article within the issue by giving the URN and fragment which takes the users to the beginning of the article. Depending on the physical encoding of the document, URI fragment can be used to pinpoint any location within the article. If URI fragments do identify subordinate resources (as stated for instance in http://en.wikipedia.org/wiki/Fragment_identifier) we would need some guidelines on what these resources actually are.  Having a lot of experience on the use of bibliographic identifiers, I find for instance this statement from the Wikipedia page rather interesting:

The following example identifies lines 11 through 20 of a text document:
What happens when the content on lines 11-20 (why not 10-20) changes? What is identified after the author cuts the document so that it contains only 9 lines? What happens if somebody adds a few lines to the beginning of the text? What if document.txt becomes document.xxx and the relevant content is on different lines or the fragment does not work any more? These, and many other problems disappear if we decide that the URL above does not identify anything, and the fragment just indicates a location within a resource which at least used to be available in the network address given.

Logical fragments such as journal articles or book chapters may or may not be represented in the physical encoding of the resource. Be that as it may, URI fragments should not be used to identify them. For instance, in order to facilitate long term preservation and access the National Library of Finland assigns URN:NBNs to e.g. both journal articles and images within those articles. This will make it easier to migrate these resources to new file formats. If we were using just fragments for identifying articles within a journal issue, we might be in trouble if the new file format (resulting from migration) would not support the use of URI fragments.        
Your statement "if the chapter
is available as a separate item" seems to indicate that that the item
might be physically separate and therefore that URN-assigning entity
might decide to allow '#' notation to identify such items (it's true
that ISBN does not allow this, but that's a matter for the ISBN
namespace -- the NBN namespace might allow that or might allow
sub-namespaces to come up with their own syntax for fragments, using '.'
instead of '#' or whatever).

Do I understand you correctly?
Not exactly. It is possible to give an ISBN to chapter 1 of volume 1 of Don Quijote, if the chapter is for sale as an e-book. Once the book has URN:ISBN, anybody can use URI fragment to provide access to any location within the chapter. RFC 3986 would say that these users have identified subordinate parts within the chapter. A lot of hairy problems regarding e.g. the definition of subordinate parts can be avoided if we just say that in theory it is possible to specify any location within the document with a fragment, provided that has been identified by the URN.

As I see it, the mess we end up with when we assume that URI fragment actually identifies something is just another example why it is a bad idea to mix location (in this case not in the Web, but within a single document) and identification.   


In summary, I do see the potential that some fragment-like
construct that were resolved as part of the URN could be
useful.   I just don't think it's a good idea to prevent users
from addressing individual HTML-style fragments of a document
in conjunction with URNs.   And I think it would be confusing
if we repurposed '#' to mean something subtly different for
URNs than for other URIs.

+ 1 to all of the above, except that I think that the best we can have
is namespace specific fragment-like constructs.

By "namespace specific fragment-like constructs" do you mean "each
namespace is allowed to define its own constructs for identifying
fragment-like things, as long as the syntax does not involve the use of
'#' as the denotation of the start of the fragment-like thing in the
name"? Or do you think that '#' is allowed as well?
No, we should not allow "#" for namespace specific constructs.

Juha

Peter




-- 

 Juha Hakala
 Senior advisor

 The National Library of Finland 
 P.O.Box 15 (Unioninkatu 36, room 503)
 FIN-00014 Helsinki University
 tel +358 9 191 44293
--------------020800040001070200090308-- From stpeter@stpeter.im Tue Jul 9 08:58:51 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3759111E815F for ; Tue, 9 Jul 2013 08:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Upcx2WDdDTS for ; Tue, 9 Jul 2013 08:58:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2740011E8144 for ; Tue, 9 Jul 2013 08:58:40 -0700 (PDT) Received: from sjc-vpn2-881.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 66F9F413C9; Tue, 9 Jul 2013 09:59:42 -0600 (MDT) Message-ID: <51DC332C.4080309@stpeter.im> Date: Tue, 09 Jul 2013 09:58:36 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Juha Hakala References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <4A9225387F6E4CCB5BB1A018@JcK-HP8200.jck.com> <51BC8D66.9050000@network-heretics.com> <7ED5CCF8F4C22A4918928866@JcK-HP8200.jck.com> <51D6C1B0.7010004@helsinki.fi> <40BA98D4D3399F1F1597B425@[192.168.1.128]> <51DA956D.9070008@helsinki.fi> <51DB8396.7020802@stpeter.im> <51DBA50A.1060701@helsinki.fi> In-Reply-To: <51DBA50A.1060701@helsinki.fi> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:58:51 -0000 On 7/8/13 11:52 PM, Juha Hakala wrote: > Hello Peter, > > On 9.7.2013 6:29, Peter Saint-Andre wrote: >> Hi Juha, >> >> >>> Please keep in mind that tens of millions of URNs have been assigned >>> already. They cannot be deprecated, and we cannot make any fundamental >>> changes which would render old and new URNs non-interoperable. What we >>> can do is to add new functionality, such as fragments and queries, and >>> make it easier for people to use URNs by for instance changing the way >>> in which services are registered. >> Might I ask you to explain what you mean by the registration of services >> here? Are you referring to registration of namespace identifiers as in >> RFC 3406, or something else? > I mean the registration of new / altered resolution services. At the > moment we have (experimental) RFC 2483 which describes a fixed set of > resolution services necessary for URN resolution. These services are > based on the technical infrastructure of late 90's. > > Based on the experiences the National Library of Finland has got from > maintaining both a national URN resolution service and a number of > digital library applications, there are a few improvements needed: > > 1. RFC 2483 assumes that the resolution services do not need parameters. > For instance, if a user requests metadata about the resource, one size > fits all - the (non-existent) URC will do. If only it were that simple: > in practice, a user may need descriptive metadata which can be available > in many formats (MARC 21, Dublin Core, EAD, LIDO and so on) or > administrative metadata which has its own formats. So instead of having > just two services (I2C, or URI to URC, and I2Cs) we shall need either > one service for each metadata format which would be cumbersome, or > enriched I2C service which allows the user to specify either the format > or the metadata type (descriptive or administrative; the latter consists > of technical, preservation and rights metadata) wanted. Thanks, that is helpful. At this time, my main interest is in finding text for 2141bis and 3406bis that we can agree on so that the base specs can be advanced. Once that is done, I will leave work on 2483bis to people (like you) who know more about resolution services. > 2. Specifying the services in an RFC is based on the assumption that the > set of URI resolution services is relatively stable and does not require > frequent updates. It is not likely that is the case, since resolution > services depend on a technical infrastructure which has been changing > fast. Emerging services, such as digital archives, will enable us to > provide new kinds of services, which from URI resolution point of view > may be either entirely new services or additional parameters to existing > ones. > > Some examples of services that have emerged since RFC 2483 was written > (assuming, among other things, that there is a fully functional digital > archive application which interacts with the URN resolver): > > A. On the basis of the URN of work X, show me all its manifestations > (PDF, OOXML, EPUB 3 etc.) > B. On the basis of the URN of work X, show me all the other works > related to it > C. Based on the URN of manifestation X, show me all the other > manifestations of the same work > D. On the basis of preservation metadata, show me the differences > (resulting from successive migrations) between the manifestations of work X > E. On the basis of technical metadata, show me the software and > hardware requirements of using manifestation X > F. On the basis of rights metadata, show me if I can access copy Y of > manifestation X > > 3. RFC 2483 does not enable specification of formal, informal and > experimental resolution services. Such division might be useful (see > below). > > Alfred Hoenes and myself concluded that what we need is an IANA URN > resolution service registry (similar to the URN namespace registry), and > an RFC which specifies how such a registry is to be maintained. Juha, do you think this is something that needs to be specified in 3406bis? My feeling is that the IANA URN Resolution Services Registry would be defined by 2483bis. > I believe that the maintenance of the service registry is less > challenging than maintenance of the namespace registry. For each new URN > namespace, Well, for each new URN namespace for which resolution services are expected / defined. :-) > IANA / IETF should estimate if the namespace is managed well > enough and whether the identifier system meets the requirements. Meets the requirements of 3406bis or 2483bis? IMHO it is not IANA's job to perform this estimation, it is the job of the URN-NID expert reviewers or, perhaps even better, a task that the broader URN community needs to take seriously. If another SDO write an I-D and requests a NID, then we might treat that as we do for things like media types now. > For > resolution service / service parameter no such scrutiny is needed. But > it is important to maintain a central registry if them, so as to > guarantee that the users of the URNs do not re-invent the wheel. Agreed. > IANA may decide that maintaining this registry is not within its scope. > In that case URNbis should find another volunteer. IMO it is not > possible to write and RFC which specifies URN resolution service > registry and its maintenance procedure without telling who runs the show. I see IANA as a mere registrar here, not as a gatekeeper. >>> IMO, fragment is just a fragment, no matter whether it is attached to >>> URL or to URN. Even when added to a URN it does not identify anything. >> Pendantic point: if that is true, then why do we call it a fragment >> identifier component? Sure it must identify the "indicated location >> within the resource", as you say... > I do not call it fragment identifier; you do. I do not call it fragment identifier; RFC 3986 does. :-) I am trying to understand what you mean by fragment here. I think it is not the same as what RFC 3986 means, so we might want to use a different term for "sub-parts of a thing identified by a URN that are not flagged by the presence of an RFC 3986 fragment identifier". Shall we call it a "segment" to prevent confusion? > Let's use an analogy. Every house in Finland has an address. But Finnish > Ordnance Survey does not use the address as an identifier for the house; > they have an entirely different system for that. The names of cities and > streets can change, so address is not persistent enough to serve as an > identifier. > > If I want to identify an article within a journal issue, I'd never use > the identifier of the issue and a fragment which shows where the article > begins within the issue. The same article may be / will be published in > many other places, independently of the original context (the journal > issue). Any identifier which assumes that the issue is there might soon > become a real pain in the neck. It is much better idea to have separate > identifier for the article, although in order to access it one may use > also the URN of the issue plus fragment. URN plus RFC 3986 fragment identifier or URN plus namespace-specific "segment distinguisher"? > When the journal and the issue are migrated into new file format, new > identifiers will of course be assigned. A link between the old and new > manifestation is established in metadata, with the description of the > differences between the two manifestations in preservation metadata. That all makes sense. Thanks for the explanation. >>> If and when we decide to use query, then URN will have a set of services >>> and service parameters that have been specified as queries. For URLs >>> nothing will be carved in stone like this. >> Juha, do you mean that we would define stable queries that apply to all >> URNs (or all URNs within a namespace) and that service providers would >> not be encouraged or allowed to define their own non-standard queries? > I would definitely not encourage the service providers to define > non-standard queries, since that would reduce interoperability between > URN resolvers. If I need to get e.g. technical metadata for a document > held in the digital archive of the National Library of Norway, it would > be really annoying if my client app should use different service + > service parameter combination than our resolver in Finland uses. > > But it should be OK to allow service providers to specify experimental > queries and query parameters for internal usage, with an assumption that > such things may become formal services / service parameters in the future. Agreed. >>> For those who need to identify component parts ("fragments") of >>> resources, the URN syntax should provide a means of doing that in a >>> namespace specific manner. >> Here again I need to ask something I queried about in another message: >> do you mean that we would *not* allow fragments using URI '#' syntax but >> instead would leave the syntax up to the namespace (e.g., one could use >> '.' or some other character as the delimiter for fragments within a >> given namespace)? > Yes. In URNs, fragment using the URI "#" syntax should not have any > meaning beyond what RFC 3986 assigns for it. Any diversion might cause > us problems now or in the (more or less distant) future. > > Namespace specific solutions for identifying fragments (or component > parts of documents or whatever the fragment is called) may use basically > any means for fragment identification, except the URI generic syntax. > Resolvers which cope with the identifiers within that namespace must > know how treat these URNs. Most often the process will be > straightforward since identifiers for component parts are the same as > the identifiers for host documents. That seems sensible. >>> The only fundamental issue for me was the need of the URNs to be >>> actionable. IMO non-functional URN (or a URN given to a resource which >>> is not persistent) is counterproductive and should never be assigned. >>> But we have decided that there can be URNs that will not provide any >>> services, and that's it. >> Actually there are lots of "non-functional", "non-dereferencable" >> namespaces. Maybe the organizations managing those mint far fewer URNs, >> but I don't think it's productive to say that URNs that don't provide >> services (e.g., you can't dereference them to retrieve metadata) are >> counterproductive. As John says, they simply fall into a different >> category. We could have a discussion about whether it might have made >> sense to to define something other than URNs for those identifiers, but >> that's water under the bridge now and IMHO it's best to try to >> accomodate all the existing uses as best we can. > OK. >>> In the other end of the scale, we may have namespaces with plenty of >>> services, with frequent changes both to the existing services >>> (additional and deprecated features) and to the list of services (new >>> services added, old ones removed). We should design flexible means for >>> specifying the services & service parameters available within a >>> namespace in general, and provided by a resolver which supports the >>> namespace in particular. >> Mostly I see these services as a matter for specifications other than >> 2141bis. However, I now agree that we need to at least allow queries and >> fragments in the syntax (but not within the NSS), and that's all I care >> about for 2141bis. I'll leave documentation of services and URN >> resolution to someone braver than I. :-) > Great; allowing both fragment and query and thus aligning URNs with the > URI syntax as specified in RFC 3986 is at least a very good start :-). > And Alfred Hoenes has already written an I-D which outlines the IANA > registry for URN resolution services, so there is no need to start from > scratch. Excellent. I am out of time for the moment, but tonight I will try to work on proposed text for 2141bis so that we can move forward. (I would very much like to submit a revised I-D before the submission deadline next Monday.) Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Jul 9 17:40:20 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91B721F8956 for ; Tue, 9 Jul 2013 17:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.598 X-Spam-Level: X-Spam-Status: No, score=-101.598 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTsFdcDF8JQx for ; Tue, 9 Jul 2013 17:40:16 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0178421F8C20 for ; Tue, 9 Jul 2013 17:40:11 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 42768413BE; Tue, 9 Jul 2013 18:41:15 -0600 (MDT) Message-ID: <51DCAD69.9070804@stpeter.im> Date: Tue, 09 Jul 2013 18:40:09 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Juha Hakala References: <65823B328A8C0AC3E24F5E84@localhost> <51DA76E6.6040005@helsinki.fi> <51DB4D24.9050608@stpeter.im> <51DBC670.5050703@helsinki.fi> In-Reply-To: <51DBC670.5050703@helsinki.fi> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 00:40:20 -0000 Hi Juha, On 7/9/13 2:14 AM, Juha Hakala wrote: > Hello Peter, > > On 9.7.2013 2:37, Peter Saint-Andre wrote: >> Hi Juha, thank you for continuing this discussion. I think we are >> getting closer to a shared understanding. > I hope so; if we manage to agree on things then I may avoid writing > national extensions to the IETF RFCs ;-). >> >> Comments inline, with the intent of finding text we can agree on. >> >> On 7/8/13 2:23 AM, Juha Hakala wrote: >> >> The easiest >> solution is to keep both fragments and queries separate from the NSS, >> which a priori means that a URN and the same URN with fragment always >> identify the same resource. >> (And also "the same URN with query", I assume?) > Yes. But while clients should not even send the fragment to servers when > they retrieve documents, queries will be evaluated by (in this case) URN > resolvers. In a complex environment resolvers must have quite a lot of > intelligence ot cope with the situation; for instance, what the user > wants may best be met by descriptive metadata from the national > bibliography, the document itself from the institutional repository, or > the oldest possible manifestation of the work from the digital archive. >> >> Keeping fragments and queries separate from the NSS makes it easier for >> us to determine the exact text in 2141bis and 3406bis. > Good. > >> Juha, do I understand correctly that you might suggest that we >> continue to define assigned URNs (or, perhaps more precisely, URIs >> with the urn: scheme) as "urn" ":" NID ":" NSS and then specify that >> fragments and queries might be strings that can be added to an >> assigned URN? (Perhaps the term "assigned URN" is not quite right -- >> suggestions are welcome.) Thus I could see something like this in >> 2141bis: namestring = assigned-name [ "?" query ] [ "#" fragment ] >> assigned-name = "urn" ":" NID ":" NSS > > Exactly. And it might not do any harm if we make it clear that while > identifier assignment can be a managed process in some namespaces, once > the URN has been assigned, anyone - human or a machine - can add a > fragment or a query to it. Good point. I'll see what helpful text I can formulate. >>> In some circumstances it might be useful to have a URN resolution >>> service (available via a query parameter) which harvests the structure >>> of the document (chapters, parts, names of articles within a book which >>> consists of articles). But since the encoding of the documents can be >>> non-informative, it is a better idea to check descriptive metadata to >>> find out about the resource. Table of contents is probably much more >>> readable than any fragment listing. >> Juha, I admit that I still don't understand how such a dereferencing >> (or, better, metadata-retrieval) service would work. How would a client >> of this service discover the address and API of the service? > Clients would not need to know anything about it. > > Currently URN resolution services have relatively simple mapping tables > which may simply say that document with this URN is available from this > / these location / locations. These resolution services must become more > versatile with the digital library applications. In the future the > resolver has to know (for instance) where to obtain descriptive metadata > about resources, the resources themselves, or past versions of these > resources. These services may be available via 1-n applications and 1-n > APIs. Specifying them is beyond the scope of URNbis. > > What we need is a set of URN standards which does not become a > bottleneck when there is a need to specify new resolution services. It > looks like URNbis is heading to the right direction. I hope so! >> In today's >> web, I could see us defining a well-known URI (RFC 5785) at which one >> could send a request (passing the assigned URN as a parameter) and then >> receiving in response a metadata file in a format like XML or JSON. But >> IMHO that doesn't necessitate adding query strings to assigned URNs. In >> any case, if people feel that they need to add query strings onto the >> end of assigned URNs (or are already doing that in practice) then I now >> think it is acceptable to define a way to do that, as long as we say >> that it is the responsibility of each namespace that allows query >> strings (and fragment identifiers) to carefully define what those mean >> in the context of that namespace. > I'll take a look at RFC 5785. It's not really relevant to 2141bis and 3406bs, but you might find it helpful or interesting for 2483bis. >>> For identification of component parts of resources ("logical fragments") >>> one should never use URI fragments, but identifiers created on the >>> basis of namespace specific practices which must be supplied in the >>> namespace registration request. For the ISBN namespace the principle is >>> carved in stone in the standard: one can assign ISBN for e.g. a chapter >>> of a book (like chapter 1 of Don Quixote, vol. 1) if the chapter is >>> available as a separate item. For NBN, each organization assigning >>> identifiers has the freedom to decide what to do within its own >>> sub-namespace. >> Juha, I see a tension between your statements and I am hoping you can >> clarify something. >> >> As I read your email, I think you are saying that you would like to use >> fragment identifiers with '#' notation. > Yes, we should allow the use of URI fragment for indicating a location > within a resource which has already been identified by a URN. Understood. >> However, then you say that >> identification of component parts of resources should never use URI >> fragments (i.e., never use '#' notation). > The point being that URI fragments must not identify anything and > therefore they must not be a part of the NSS. OK. I will work to write some text reflecting that understanding. >> It would help me if you could >> explain when you think URI fragment syntax is appropriate and when it is >> not. What exactly are "logical fragments"? Are there other kinds of >> fragments (e.g., "physical fragments")? > Yes. As I see it, URI fragment can be applied to physical fragments in > a document that has a URN. For instance, if a resource is a digitized > journal issue with a single URN:NBN, it is possible to cite an article > within the issue by giving the URN and fragment which takes the users to > the beginning of the article. Depending on the physical encoding of the > document, URI fragment can be used to pinpoint any location within the > article. If URI fragments do identify subordinate resources (as stated > for instance in http://en.wikipedia.org/wiki/Fragment_identifier) we > would need some guidelines on what these resources actually are. It seems to me that it's the responsibility of the manager / spec for a particular URN namespace to define that (since it will depend very much on the kinds of URNs being minted / resources being named). > Having > a lot of experience on the use of bibliographic identifiers, I find for > instance this statement from the Wikipedia page rather interesting: Don't believe everything you read on Wikipedia. :-) >> The following example identifies lines 11 through 20 of a text document: >> >> * |http://example.com/document.txt#line=10,20| >> > What happens when the content on lines 11-20 (why not 10-20) changes? > What is identified after the author cuts the document so that it > contains only 9 lines? What happens if somebody adds a few lines to the > beginning of the text? What if document.txt becomes document.xxx and the > relevant content is on different lines or the fragment does not work any > more? These, and many other problems disappear if we decide that the URL > above does not identify anything, and the fragment just indicates a > location within a resource which at least used to be available in the > network address given. Right. > Logical fragments such as journal articles or book chapters may or may > not be represented in the physical encoding of the resource. Be that as > it may, URI fragments should not be used to identify them. For instance, > in order to facilitate long term preservation and access the National > Library of Finland assigns URN:NBNs to e.g. both journal articles and > images within those articles. This will make it easier to migrate these > resources to new file formats. If we were using just fragments for > identifying articles within a journal issue, we might be in trouble if > the new file format (resulting from migration) would not support the use > of URI fragments. OK, that makes sense. >> Your statement "if the chapter >> is available as a separate item" seems to indicate that that the item >> might be physically separate and therefore that URN-assigning entity >> might decide to allow '#' notation to identify such items (it's true >> that ISBN does not allow this, but that's a matter for the ISBN >> namespace -- the NBN namespace might allow that or might allow >> sub-namespaces to come up with their own syntax for fragments, using '.' >> instead of '#' or whatever). >> >> Do I understand you correctly? > Not exactly. It is possible to give an ISBN to chapter 1 of volume 1 of > Don Quijote, if the chapter is for sale as an e-book. Once the book has > URN:ISBN, anybody can use URI fragment to provide access to any location > within the chapter. RFC 3986 would say that these users have identified > subordinate parts within the chapter. A lot of hairy problems regarding > e.g. the definition of subordinate parts can be avoided if we just say > that in theory it is possible to specify any location within the > document with a fragment, provided that has been identified by the URN. > > As I see it, the mess we end up with when we assume that URI fragment > actually identifies something is just another example why it is a bad > idea to mix location (in this case not in the Web, but within a single > document) and identification. Yes, naming is hard. If I may paraphrase you, an identifier (in this case a URN) provides a name for a resource, whereas a fragment merely distinguishes a particular location within or segment of a resource. >>>>> In summary, I do see the potential that some fragment-like >>>>> construct that were resolved as part of the URN could be >>>>> useful. I just don't think it's a good idea to prevent users >>>>> from addressing individual HTML-style fragments of a document >>>>> in conjunction with URNs. And I think it would be confusing >>>>> if we repurposed '#' to mean something subtly different for >>>>> URNs than for other URIs. >>> + 1 to all of the above, except that I think that the best we can have >>> is namespace specific fragment-like constructs. >> By "namespace specific fragment-like constructs" do you mean "each >> namespace is allowed to define its own constructs for identifying >> fragment-like things, as long as the syntax does not involve the use of >> '#' as the denotation of the start of the fragment-like thing in the >> name"? Or do you think that '#' is allowed as well? > No, we should not allow "#" for namespace specific constructs. Great, thanks for clariying your statement. Peter -- Peter Saint-Andre https://stpeter.im/ From juha.hakala@helsinki.fi Wed Jul 10 01:08:30 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCDC21F9F65 for ; Wed, 10 Jul 2013 01:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.841 X-Spam-Level: X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[AWL=0.758, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id firSRcazCvN2 for ; Wed, 10 Jul 2013 01:08:25 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 01BB521F9F16 for ; Wed, 10 Jul 2013 01:08:24 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r6A889fM008250 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 10 Jul 2013 11:08:10 +0300 Message-ID: <51DD1669.1070501@helsinki.fi> Date: Wed, 10 Jul 2013 11:08:09 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <4A9225387F6E4CCB5BB1A018@JcK-HP8200.jck.com> <51BC8D66.9050000@network-heretics.com> <7ED5CCF8F4C22A4918928866@JcK-HP8200.jck.com> <51D6C1B0.7010004@helsinki.fi> <40BA98D4D3399F1F1597B425@[192.168.1.128]> <51DA956D.9070008@helsinki.fi> <51DB8396.7020802@stpeter.im> <51DBA50A.1060701@helsinki.fi> <51DC332C.4080309@stpeter.im> In-Reply-To: <51DC332C.4080309@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 08:08:30 -0000 Hi, On 9.7.2013 18:58, Peter Saint-Andre wrote: > Thanks, that is helpful. At this time, my main interest is in finding > text for 2141bis and 3406bis that we can agree on so that the base > specs can be advanced. Once that is done, I will leave work on 2483bis > to people (like you) who know more about resolution services. OK. >> >> Alfred Hoenes and myself concluded that what we need is an IANA URN >> resolution service registry (similar to the URN namespace registry), and >> an RFC which specifies how such a registry is to be maintained. > Juha, do you think this is something that needs to be specified in > 3406bis? My feeling is that the IANA URN Resolution Services Registry > would be defined by 2483bis. I share your view that 2483bis is a better place to the registry specification than 3406bis. But 3406bis must refer to the registry specification, so that people know how to proceed when their namespace registrations include new services / service parameters. 3406bis might also be a place where to explain the problems which may be caused by using private services / service parameters. An additional benefit from using rfc2483bis is that we can open the registry to other PID systems, in case they want to formally register the services they provide. For instance the ARK system (http://datatracker.ietf.org/doc/draft-kunze-ark/) specifies three services, one of which is not covered in RFC 2483 (access to the statement which describes the host organisation's commitment to preserve the resource in long term). ARK has its own syntactic tools to request this service, but it might still be possible to specify it in the registry so as to improve interoperability between these two identifiers. > >> I believe that the maintenance of the service registry is less >> challenging than maintenance of the namespace registry. For each new URN >> namespace, > Well, for each new URN namespace for which resolution services are > expected / defined. :-) OK. > >> IANA / IETF should estimate if the namespace is managed well >> enough and whether the identifier system meets the requirements. > Meets the requirements of 3406bis or 2483bis? No, I mean the generic requirements for URNs (persistent, location-independent and preferably also unique) which are listed in RFC 2141 and in many other RFCs. Namespace registration request should contain enough information to make sure that these requirements are met. The registration should also describe how the namespace is managed, but it will be harder to evaluate this information. > > IMHO it is not IANA's job to perform this estimation, it is the job of > the URN-NID expert reviewers or, perhaps even better, a task that the > broader URN community needs to take seriously. If another SDO write an > I-D and requests a NID, then we might treat that as we do for things > like media types now. OK. I thought that the URN-NID expert reviewers are using the IANA hat when they are performing the job. I have no idea if any applications have ever been turned down, due to technical or other shortcomings. As of this writing the URN community is not yet ready to take over the responsibility of reviewing namespace registration requests. But eventually it may be a good idea to delegate the task from IANA to the users of the URN system themselves. >> IANA may decide that maintaining this registry is not within its scope. >> In that case URNbis should find another volunteer. IMO it is not >> possible to write and RFC which specifies URN resolution service >> registry and its maintenance procedure without telling who runs the show. > I see IANA as a mere registrar here, not as a gatekeeper. OK. It seems to me that maintenance of the service registry is also something that is in the interests of the URN user community. Co-ordination would reduce the possibility of registering overlapping services and minimize the risk of simultaneous preparation of identical service registration requests. > >>>> IMO, fragment is just a fragment, no matter whether it is attached to >>>> URL or to URN. Even when added to a URN it does not identify anything. >>> Pendantic point: if that is true, then why do we call it a fragment >>> identifier component? Sure it must identify the "indicated location >>> within the resource", as you say... >> I do not call it fragment identifier; you do. > I do not call it fragment identifier; RFC 3986 does. :-) Unfortunately... > > I am trying to understand what you mean by fragment here. I think it is > not the same as what RFC 3986 means, so we might want to use a different > term for "sub-parts of a thing identified by a URN that are not flagged > by the presence of an RFC 3986 fragment identifier". Shall we call it a > "segment" to prevent confusion? When RFC 3986 fragment is added to the URN, even "fragment identifier" is confusing indeed since we do not want to give it any role in identification. It is very hard for me to see what the fragment would identify since fragment can in theory point to any location within the document. There does not need to be any subordinate resources (although there can be one). Can we just say that URI fragment can be used to indicate a location within the identified resource, but that in the URN system it does not formally identify any component parts of the resource? Then we can make a statement that there can be namespace specific practices for identification of component parts, such as "an article in a single issue of a periodical, a chapter in a book, a band on a phonodisc, and a map on a single sheet that contains several maps", and that these practices shall be specified in namespace registration requests. > > It is much better idea to have separate > identifier for the article, although in order to access it one may use > also the URN of the issue plus fragment. > URN plus RFC 3986 fragment identifier or URN plus namespace-specific > "segment distinguisher"? The two options above could be described as "adding RFC 3986 fragment to the URN of a resource (serial issue)", and "creating a URN for a component part of the resource (serial article)". The former approach allows the users to locate the article within the issue and is sufficient for e.g. providing a reference to the article. > > I am out of time for the moment, but tonight I will try to work on > proposed text for 2141bis so that we can move forward. (I would very > much like to submit a revised I-D before the submission deadline next > Monday.) > Peter OK. I hope you'll be able to finish the work on time. The task may be a bit easier if you cut and paste relevant sections from the last 2141bis I-D written by Alfred Hoenes back to your text. There is a lot of stuff Alfred wrote that does not require too much editing now that we agree (more or less) on e.g. how to use fragment and query. For instance the analysis of semantic equivalence of various URNs in Alfred's text was based on the idea that fragment and query are not part of the NSS. Whether you use the old I-D or not, it would be nice if Alfred were mentioned as one of the authors since he had a major role in e.g. formulating the usage of fragment and query. Once the new version of the 2141bis is complete, I'll check what needs to be done to the ISBN and NBN namespace registrations. Any work on 2483bis has to wait for a while, not least because for now it is not even on the agenda of URNbis. Juha -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 From stpeter@stpeter.im Wed Jul 10 15:06:11 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF5A21F893E for ; Wed, 10 Jul 2013 15:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-c3eLF5XTcy for ; Wed, 10 Jul 2013 15:06:06 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 641E621F8F61 for ; Wed, 10 Jul 2013 15:06:04 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B4EFC413BC; Wed, 10 Jul 2013 16:07:10 -0600 (MDT) Message-ID: <51DDDAC9.60308@stpeter.im> Date: Wed, 10 Jul 2013 16:06:01 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Juha Hakala References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <4A9225387F6E4CCB5BB1A018@JcK-HP8200.jck.com> <51BC8D66.9050000@network-heretics.com> <7ED5CCF8F4C22A4918928866@JcK-HP8200.jck.com> <51D6C1B0.7010004@helsinki.fi> <40BA98D4D3399F1F1597B425@[192.168.1.128]> <51DA956D.9070008@helsinki.fi> <51DB8396.7020802@stpeter.im> <51DBA50A.1060701@helsinki.fi> <51DC332C.4080309@stpeter.im> In-Reply-To: <51DC332C.4080309@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 22:06:11 -0000 Proposed text at end. On 7/9/13 9:58 AM, Peter Saint-Andre wrote: > On 7/8/13 11:52 PM, Juha Hakala wrote: >> Hello Peter, >> >> On 9.7.2013 6:29, Peter Saint-Andre wrote: >>> Hi Juha, >>> >>> >>>> Please keep in mind that tens of millions of URNs have been assigned >>>> already. They cannot be deprecated, and we cannot make any fundamental >>>> changes which would render old and new URNs non-interoperable. What we >>>> can do is to add new functionality, such as fragments and queries, and >>>> make it easier for people to use URNs by for instance changing the way >>>> in which services are registered. >>> Might I ask you to explain what you mean by the registration of services >>> here? Are you referring to registration of namespace identifiers as in >>> RFC 3406, or something else? >> I mean the registration of new / altered resolution services. At the >> moment we have (experimental) RFC 2483 which describes a fixed set of >> resolution services necessary for URN resolution. These services are >> based on the technical infrastructure of late 90's. >> >> Based on the experiences the National Library of Finland has got from >> maintaining both a national URN resolution service and a number of >> digital library applications, there are a few improvements needed: >> >> 1. RFC 2483 assumes that the resolution services do not need parameters. >> For instance, if a user requests metadata about the resource, one size >> fits all - the (non-existent) URC will do. If only it were that simple: >> in practice, a user may need descriptive metadata which can be available >> in many formats (MARC 21, Dublin Core, EAD, LIDO and so on) or >> administrative metadata which has its own formats. So instead of having >> just two services (I2C, or URI to URC, and I2Cs) we shall need either >> one service for each metadata format which would be cumbersome, or >> enriched I2C service which allows the user to specify either the format >> or the metadata type (descriptive or administrative; the latter consists >> of technical, preservation and rights metadata) wanted. > > Thanks, that is helpful. > > At this time, my main interest is in finding text for 2141bis and > 3406bis that we can agree on so that the base specs can be advanced. > Once that is done, I will leave work on 2483bis to people (like you) who > know more about resolution services. > >> 2. Specifying the services in an RFC is based on the assumption that the >> set of URI resolution services is relatively stable and does not require >> frequent updates. It is not likely that is the case, since resolution >> services depend on a technical infrastructure which has been changing >> fast. Emerging services, such as digital archives, will enable us to >> provide new kinds of services, which from URI resolution point of view >> may be either entirely new services or additional parameters to existing >> ones. >> >> Some examples of services that have emerged since RFC 2483 was written >> (assuming, among other things, that there is a fully functional digital >> archive application which interacts with the URN resolver): >> >> A. On the basis of the URN of work X, show me all its manifestations >> (PDF, OOXML, EPUB 3 etc.) >> B. On the basis of the URN of work X, show me all the other works >> related to it >> C. Based on the URN of manifestation X, show me all the other >> manifestations of the same work >> D. On the basis of preservation metadata, show me the differences >> (resulting from successive migrations) between the manifestations of work X >> E. On the basis of technical metadata, show me the software and >> hardware requirements of using manifestation X >> F. On the basis of rights metadata, show me if I can access copy Y of >> manifestation X >> >> 3. RFC 2483 does not enable specification of formal, informal and >> experimental resolution services. Such division might be useful (see >> below). >> >> Alfred Hoenes and myself concluded that what we need is an IANA URN >> resolution service registry (similar to the URN namespace registry), and >> an RFC which specifies how such a registry is to be maintained. > > Juha, do you think this is something that needs to be specified in > 3406bis? My feeling is that the IANA URN Resolution Services Registry > would be defined by 2483bis. > >> I believe that the maintenance of the service registry is less >> challenging than maintenance of the namespace registry. For each new URN >> namespace, > > Well, for each new URN namespace for which resolution services are > expected / defined. :-) > >> IANA / IETF should estimate if the namespace is managed well >> enough and whether the identifier system meets the requirements. > > Meets the requirements of 3406bis or 2483bis? > > IMHO it is not IANA's job to perform this estimation, it is the job of > the URN-NID expert reviewers or, perhaps even better, a task that the > broader URN community needs to take seriously. If another SDO write an > I-D and requests a NID, then we might treat that as we do for things > like media types now. > >> For >> resolution service / service parameter no such scrutiny is needed. But >> it is important to maintain a central registry if them, so as to >> guarantee that the users of the URNs do not re-invent the wheel. > > Agreed. > >> IANA may decide that maintaining this registry is not within its scope. >> In that case URNbis should find another volunteer. IMO it is not >> possible to write and RFC which specifies URN resolution service >> registry and its maintenance procedure without telling who runs the show. > > I see IANA as a mere registrar here, not as a gatekeeper. > >>>> IMO, fragment is just a fragment, no matter whether it is attached to >>>> URL or to URN. Even when added to a URN it does not identify anything. >>> Pendantic point: if that is true, then why do we call it a fragment >>> identifier component? Sure it must identify the "indicated location >>> within the resource", as you say... >> I do not call it fragment identifier; you do. > > I do not call it fragment identifier; RFC 3986 does. :-) > > I am trying to understand what you mean by fragment here. I think it is > not the same as what RFC 3986 means, so we might want to use a different > term for "sub-parts of a thing identified by a URN that are not flagged > by the presence of an RFC 3986 fragment identifier". Shall we call it a > "segment" to prevent confusion? > >> Let's use an analogy. Every house in Finland has an address. But Finnish >> Ordnance Survey does not use the address as an identifier for the house; >> they have an entirely different system for that. The names of cities and >> streets can change, so address is not persistent enough to serve as an >> identifier. >> >> If I want to identify an article within a journal issue, I'd never use >> the identifier of the issue and a fragment which shows where the article >> begins within the issue. The same article may be / will be published in >> many other places, independently of the original context (the journal >> issue). Any identifier which assumes that the issue is there might soon >> become a real pain in the neck. It is much better idea to have separate >> identifier for the article, although in order to access it one may use >> also the URN of the issue plus fragment. > > URN plus RFC 3986 fragment identifier or URN plus namespace-specific > "segment distinguisher"? > >> When the journal and the issue are migrated into new file format, new >> identifiers will of course be assigned. A link between the old and new >> manifestation is established in metadata, with the description of the >> differences between the two manifestations in preservation metadata. > > That all makes sense. Thanks for the explanation. > >>>> If and when we decide to use query, then URN will have a set of services >>>> and service parameters that have been specified as queries. For URLs >>>> nothing will be carved in stone like this. >>> Juha, do you mean that we would define stable queries that apply to all >>> URNs (or all URNs within a namespace) and that service providers would >>> not be encouraged or allowed to define their own non-standard queries? >> I would definitely not encourage the service providers to define >> non-standard queries, since that would reduce interoperability between >> URN resolvers. If I need to get e.g. technical metadata for a document >> held in the digital archive of the National Library of Norway, it would >> be really annoying if my client app should use different service + >> service parameter combination than our resolver in Finland uses. >> >> But it should be OK to allow service providers to specify experimental >> queries and query parameters for internal usage, with an assumption that >> such things may become formal services / service parameters in the future. > > Agreed. > >>>> For those who need to identify component parts ("fragments") of >>>> resources, the URN syntax should provide a means of doing that in a >>>> namespace specific manner. >>> Here again I need to ask something I queried about in another message: >>> do you mean that we would *not* allow fragments using URI '#' syntax but >>> instead would leave the syntax up to the namespace (e.g., one could use >>> '.' or some other character as the delimiter for fragments within a >>> given namespace)? >> Yes. In URNs, fragment using the URI "#" syntax should not have any >> meaning beyond what RFC 3986 assigns for it. Any diversion might cause >> us problems now or in the (more or less distant) future. >> >> Namespace specific solutions for identifying fragments (or component >> parts of documents or whatever the fragment is called) may use basically >> any means for fragment identification, except the URI generic syntax. >> Resolvers which cope with the identifiers within that namespace must >> know how treat these URNs. Most often the process will be >> straightforward since identifiers for component parts are the same as >> the identifiers for host documents. > > That seems sensible. > >>>> The only fundamental issue for me was the need of the URNs to be >>>> actionable. IMO non-functional URN (or a URN given to a resource which >>>> is not persistent) is counterproductive and should never be assigned. >>>> But we have decided that there can be URNs that will not provide any >>>> services, and that's it. >>> Actually there are lots of "non-functional", "non-dereferencable" >>> namespaces. Maybe the organizations managing those mint far fewer URNs, >>> but I don't think it's productive to say that URNs that don't provide >>> services (e.g., you can't dereference them to retrieve metadata) are >>> counterproductive. As John says, they simply fall into a different >>> category. We could have a discussion about whether it might have made >>> sense to to define something other than URNs for those identifiers, but >>> that's water under the bridge now and IMHO it's best to try to >>> accomodate all the existing uses as best we can. >> OK. >>>> In the other end of the scale, we may have namespaces with plenty of >>>> services, with frequent changes both to the existing services >>>> (additional and deprecated features) and to the list of services (new >>>> services added, old ones removed). We should design flexible means for >>>> specifying the services & service parameters available within a >>>> namespace in general, and provided by a resolver which supports the >>>> namespace in particular. >>> Mostly I see these services as a matter for specifications other than >>> 2141bis. However, I now agree that we need to at least allow queries and >>> fragments in the syntax (but not within the NSS), and that's all I care >>> about for 2141bis. I'll leave documentation of services and URN >>> resolution to someone braver than I. :-) >> Great; allowing both fragment and query and thus aligning URNs with the >> URI syntax as specified in RFC 3986 is at least a very good start :-). >> And Alfred Hoenes has already written an I-D which outlines the IANA >> registry for URN resolution services, so there is no need to start from >> scratch. > > Excellent. > > I am out of time for the moment, but tonight I will try to work on > proposed text for 2141bis so that we can move forward. (I would very > much like to submit a revised I-D before the submission deadline next > Monday.) Here is some proposed text for 2141bis. SECTION 5 OLD URN = "urn" ":" NID ":" NSS ; ; the URI scheme ("urn") is case-insensitive ; NID = (alphanum) 0*30(ldh) (alphanum) ; ; alphanum is defined in RFC 3986 ; ldh = alphanum / "-" NSS = 1*(pchar) ; ; pchar is defined in RFC 3986 ; NEW namestring = assigned-name [ "?" query ] [ "#" fragment ] ; ; query and fragment are defined in RFC 3986 ; assigned-name = "urn" ":" NID ":" NSS ; ; the URI scheme ("urn") is case-insensitive ; NID = (alphanum) 0*30(ldh) (alphanum) ; ; alphanum is defined in RFC 3986 ; ldh = alphanum / "-" NSS = 1*(pchar) ; ; pchar is defined in RFC 3986 ; SECTION 5.3 (new section) 5.3. Query Component and Fragment Identifier Component The URI specification [RFC3986] allows a query component, a fragment identifier component, or both after the path component of a URI, where the character '?' is used as a separator to denote the beginning of the query component and the character '#' is used as a separator to denote the beginning of the fragment identifier component. The original URN syntax specification [RFC2141] reserved the '?' and '#' characters for future developments. This specification aligns URN syntax with URI syntax by allowing the query component and fragment identifier component after (not within) the Namespace Specific String (NSS). However, this specification does not define the applicability and semantics of the query component or the fragment identifier component in URNs. Additional specifications might establish these matters for URN-related services (such as resolution) or for individual URN namespaces. In particular, methods for distinguishing the component parts of resources named by URNs within individual namespaces are the responsibility of specifications for those namespaces (e.g., they might use URI fragment identifier component syntax or some namespace-specific syntax). Feedback is welcome. Peter -- Peter Saint-Andre https://stpeter.im/ From juha.hakala@helsinki.fi Wed Jul 10 23:08:38 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534E221F9C97 for ; Wed, 10 Jul 2013 23:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.667 X-Spam-Level: X-Spam-Status: No, score=-5.667 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NR8SMxXJ2Cjy for ; Wed, 10 Jul 2013 23:08:26 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4034A21F9BB1 for ; Wed, 10 Jul 2013 23:08:24 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r6B68KOr017569 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 11 Jul 2013 09:08:22 +0300 Message-ID: <51DE4BD4.9010805@helsinki.fi> Date: Thu, 11 Jul 2013 09:08:20 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: urn@ietf.org References: <51BE989B.3000700@network-heretics.com> <51C365D8.4070004@network-heretics.com> <51C3C1EB.7050007@network-heretics.com> <51C3FBBC.4050504@gmx.de> <51C4DE1F.2090704@network-heretics.com> <51C55B71.9050504@gmx.de> <51C5786B.6000708@network-heretics.com> <51C5795E.9070702@gmx.de> <51C5B964.7060105@network-heretics.com> In-Reply-To: <51C5B964.7060105@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] several different proposals for URN syntax to include fragments and queries X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 06:08:38 -0000 Hello, On 22.6.2013 17:49, Keith Moore wrote: > On 06/22/2013 09:16 AM, Barry Leiba wrote: > > None of the examples you cited above require use of a query string > within the URN. A URN can be associated with a query without having > to contain a query string. The only reason for a URN to contain a > query string is if you want to be able to substitute one query string > for another, or to expose the relationship between the query and the > base resource (i.e. the query engine) for some other reason. > >> And yet I can see value, for research and reference purposes, to have >> "a URN" that names "all books written by Barack Obama" (as opposed to >> "all books *about* Barack Obama", which, to me, would clearly be a >> transient query). > > No, "all books about Barack Obama" would not clearly be a transient > query. In OCLC's Worldcat database it is easy to search resources created by Obama http://www.worldcat.org/search?q=au%3Aobama%2C+barack&qt=advanced&dblist=638 or resources about him: http://www.worldcat.org/search?q=kw%3Aobama%2C+barack&qt=advanced&dblist=638 The results sets overlap, but in the former set there are about 1000 hits, the latter has almost 12.000. There are no plans to assign URNs or other truly persistent identifiers to database searches such as the ones above, not least because the result sets will be constantly growing. The two URLs above are not likely to be persistent in the national library scale of things, and they don't even need to be that. Hypothetical examples of meaningful ways of using URN + query in this particular context include the following: 1. Using URN:ISTC, find all versions (printed and audio book, translations to other languages, etc) of one of Obama's books, Dreams from my father. 2. Using URN:ISBN, retrieve PDF edition of Dreams of my father or find out if there are other digital editions of it 3. Using URN:ISBN, find out if there is a copy of the PDF edition out there that I can access 4. Using URN:ISBN, find out if the PDF edition of the book is the earliest (most authentic) digital edition of the book, and if not, what changes in the look and feel & content are there, compared to the earliest version The starting point is something stable such as a work (or its author) or its manifestation which can get an identifier. From there it will be possible to proceed in various ways, depending on the users' needs. > > Again, when we talk about persistence of a URN, we're not talking > about whether the results are the same from one reference of the URN > to the next, we're talking about whether the meaning of the URN changes. Since query is not part of the URN, what is being identified does not change. In that sense the meaning of the URN does not change. But each example above would use different queries to ask the URN resolver to launch different resolution services. > > The problem with having a URN that contains a query string be > persistent is that it's hard to nail down, in technical terms, what it > means for a query to be persistent across all possible query > strings. And to me the simplest answer seems to be that while the > base URN is expected to be persistent, a URN that contains a query > string (or for that matter a fragment ID) has no assurance of > persistence. Since URN resolution services are dependent on technical infrastructure, there may be cases when the required service cannot be supplied. But generally speaking adding a query should have no impact on persistence of the URN. If the URN is actionable at all, there is always at least one service available which could be specified by a query (such as e.g. ?s=U2R if the resource itself is required). Juha > > Keith > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 From juha.hakala@helsinki.fi Thu Jul 11 00:14:47 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCAC21F9D1E for ; Thu, 11 Jul 2013 00:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.015 X-Spam-Level: X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.584, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyRIwU8zLbDQ for ; Thu, 11 Jul 2013 00:14:42 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9069F21F9D31 for ; Thu, 11 Jul 2013 00:14:39 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r6B7EauZ006343 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 11 Jul 2013 10:14:37 +0300 Message-ID: <51DE5B5C.7070204@helsinki.fi> Date: Thu, 11 Jul 2013 10:14:36 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <4A9225387F6E4CCB5BB1A018@JcK-HP8200.jck.com> <51BC8D66.9050000@network-heretics.com> <7ED5CCF8F4C22A4918928866@JcK-HP8200.jck.com> <51D6C1B0.7010004@helsinki.fi> <40BA98D4D3399F1F1597B425@[192.168.1.128]> <51DA956D.9070008@helsinki.fi> <51DB8396.7020802@stpeter.im> <51DBA50A.1060701@helsinki.fi> <51DC332C.4080309@stpeter.im> <51DDDAC9.60308@stpeter.im> In-Reply-To: <51DDDAC9.60308@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 07:14:48 -0000 Hello, A few suggestions: On 11.7.2013 1:06, Peter Saint-Andre wrote: > Here is some proposed text for 2141bis. > > SECTION 5 > > OLD > > URN = "urn" ":" NID ":" NSS > ; > ; the URI scheme ("urn") is case-insensitive > ; > NID = (alphanum) 0*30(ldh) (alphanum) > ; > ; alphanum is defined in RFC 3986 > ; > ldh = alphanum / "-" > NSS = 1*(pchar) > ; > ; pchar is defined in RFC 3986 > ; > > NEW > > > namestring = assigned-name [ "?" query ] [ "#" fragment ] > ; > ; query and fragment are defined in RFC 3986 > ; > assigned-name = "urn" ":" NID ":" NSS > ; > ; the URI scheme ("urn") is case-insensitive > ; > NID = (alphanum) 0*30(ldh) (alphanum) > ; > ; alphanum is defined in RFC 3986 > ; > ldh = alphanum / "-" > NSS = 1*(pchar) > ; > ; pchar is defined in RFC 3986 > ; Fine with me. Some (most?) query / fragment combinations would not make sense, but that doesn't need to be discussed here. > SECTION 5.3 (new section) > > 5.3. Query Component and Fragment Identifier Component > > The URI specification [RFC3986] allows a query component, a fragment > identifier component, or both after the path component of a URI, > where the character '?' is used as a separator to denote the > beginning of the query component and the character '#' is used as a > separator to denote the beginning of the fragment identifier > component. The original URN syntax specification [RFC2141] reserved > the '?' and '#' characters for future developments. This > specification aligns URN syntax with URI syntax by allowing the query > component and fragment identifier component after (not within) the > Namespace Specific String (NSS). I do not know how obvious things should be made. But you could add here something like this: In the URN context, query can be used for e.g. requesting a resolution service. Fragment can be used for distinguishing a particular location within or a segment of a resource identified by the NSS. > However, this specification does > not define the applicability and semantics of the query component or > the fragment identifier component in URNs. Additional specifications > might establish these matters for URN-related services (such as > resolution) or for individual URN namespaces. In particular, methods > for distinguishing the component parts of resources named by URNs > within individual namespaces are the responsibility of specifications > for those namespaces (e.g., they might use URI fragment identifier > component syntax or some namespace-specific syntax). How about "responsibility of namespace registration requests and other specifications for those namespaces (e.g., they may use some namespace-specific syntax)."? Giving URI fragment identifier a prominent role here might confuse people and make them believe that fragments do identify something after all. Is it necessary to mention here or somewhere else in 2141bis that the identifier assignment can be a managed process (depending on the namespace), but anyone can add a query and / or fragment to basically any URN once the identifier has been assigned. Juha > > Feedback is welcome. > > Peter > -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 From stpeter@stpeter.im Thu Jul 11 16:51:23 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B3221F9C54 for ; Thu, 11 Jul 2013 16:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.411 X-Spam-Level: X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUL4Yv-sn2iS for ; Thu, 11 Jul 2013 16:51:18 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AE45A21F9B30 for ; Thu, 11 Jul 2013 16:51:18 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6C1D04134B; Thu, 11 Jul 2013 17:52:29 -0600 (MDT) Message-ID: <51DF44F5.8080408@stpeter.im> Date: Thu, 11 Jul 2013 17:51:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Juha Hakala References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <4A9225387F6E4CCB5BB1A018@JcK-HP8200.jck.com> <51BC8D66.9050000@network-heretics.com> <7ED5CCF8F4C22A4918928866@JcK-HP8200.jck.com> <51D6C1B0.7010004@helsinki.fi> <40BA98D4D3399F1F1597B425@[192.168.1.128]> <51DA956D.9070008@helsinki.fi> <51DB8396.7020802@stpeter.im> <51DBA50A.1060701@helsinki.fi> <51DC332C.4080309@stpeter.im> <51DDDAC9.60308@stpeter.im> <51DE5B5C.7070204@helsinki.fi> In-Reply-To: <51DE5B5C.7070204@helsinki.fi> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 23:51:24 -0000 On 7/11/13 1:14 AM, Juha Hakala wrote: > Hello, > > A few suggestions: Thanks for the feedback. We're getting closer... > On 11.7.2013 1:06, Peter Saint-Andre wrote: >> Here is some proposed text for 2141bis. >> >> SECTION 5 >> >> OLD >> >> URN = "urn" ":" NID ":" NSS >> ; >> ; the URI scheme ("urn") is case-insensitive >> ; >> NID = (alphanum) 0*30(ldh) (alphanum) >> ; >> ; alphanum is defined in RFC 3986 >> ; >> ldh = alphanum / "-" >> NSS = 1*(pchar) >> ; >> ; pchar is defined in RFC 3986 >> ; >> >> NEW >> >> >> namestring = assigned-name [ "?" query ] [ "#" fragment ] >> ; >> ; query and fragment are defined in RFC 3986 >> ; >> assigned-name = "urn" ":" NID ":" NSS >> ; >> ; the URI scheme ("urn") is case-insensitive >> ; >> NID = (alphanum) 0*30(ldh) (alphanum) >> ; >> ; alphanum is defined in RFC 3986 >> ; >> ldh = alphanum / "-" >> NSS = 1*(pchar) >> ; >> ; pchar is defined in RFC 3986 >> ; > Fine with me. Some (most?) query / fragment combinations would not make > sense, but that doesn't need to be discussed here. Agreed. >> SECTION 5.3 (new section) >> >> 5.3. Query Component and Fragment Identifier Component >> >> The URI specification [RFC3986] allows a query component, a fragment >> identifier component, or both after the path component of a URI, >> where the character '?' is used as a separator to denote the >> beginning of the query component and the character '#' is used as a >> separator to denote the beginning of the fragment identifier >> component. The original URN syntax specification [RFC2141] reserved >> the '?' and '#' characters for future developments. This >> specification aligns URN syntax with URI syntax by allowing the query >> component and fragment identifier component after (not within) the >> Namespace Specific String (NSS). > I do not know how obvious things should be made. But you could add here > something like this: > > In the URN context, query can be used for e.g. requesting a resolution > service. Fragment can be used for distinguishing a particular location > within or a segment of a resource identified by the NSS. >> However, this specification does >> not define the applicability and semantics of the query component or >> the fragment identifier component in URNs. Additional specifications >> might establish these matters for URN-related services (such as >> resolution) or for individual URN namespaces. In particular, methods >> for distinguishing the component parts of resources named by URNs >> within individual namespaces are the responsibility of specifications >> for those namespaces (e.g., they might use URI fragment identifier >> component syntax or some namespace-specific syntax). > How about "responsibility of namespace registration requests and other > specifications for those namespaces (e.g., they may use some > namespace-specific syntax)."? > > Giving URI fragment identifier a prominent role here might confuse > people and make them believe that fragments do identify something after > all. Here is revised text: ### 5.3. Query Component and Fragment Identifier Component The URI specification [RFC3986] allows a query component, a fragment identifier component, or both after the path component of a URI, where the character '?' is used as a separator to denote the beginning of the query component and the character '#' is used as a separator to denote the beginning of the fragment identifier component. The original URN syntax specification [RFC2141] reserved the '?' and '#' characters for future developments. This specification aligns URN syntax with URI syntax by allowing the query component and fragment identifier component after (not within) the Namespace Specific String (NSS). This specification does not define the applicability and semantics of the query component or the fragment identifier component in URNs. Additional specifications might establish these matters for URN- related services (such as resolution) or for individual URN namespaces. For example, it is possible that the query component might be used in requests to URN resolution services, or that the URI fragment component might be used to distinguish the component parts of resources named by URNs. However, defining such usage is left to specifications for URN resolution services, namespace registration requests and specifications for individual namespaces (which might use some namespace-specific syntax instead of the URI fragment component), and other appropriate documentation (such as policy documents governing the management of a given URN namespace). ### > Is it necessary to mention here or somewhere else in 2141bis that the > identifier assignment can be a managed process (depending on the > namespace), but anyone can add a query and / or fragment to basically > any URN once the identifier has been assigned. Perhaps. I'll look at this further a bit later tonight and propose some more text. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Jul 11 21:08:30 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E71A21E8090 for ; Thu, 11 Jul 2013 21:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApfQE7dr3NkF for ; Thu, 11 Jul 2013 21:08:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D990C21E808E for ; Thu, 11 Jul 2013 21:08:24 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7E0924134B; Thu, 11 Jul 2013 22:09:35 -0600 (MDT) Message-ID: <51DF8137.1020604@stpeter.im> Date: Thu, 11 Jul 2013 22:08:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Juha Hakala References: <93D12CA26D01683582E31B95@JcK-HP8200.jck.com> <51BA7AAB.4080301@network-heretics.com> <51BA9BCA.7080407@stpeter.im> <51BAA2B2.5010602@network-heretics.com> <51BB743B.2020007@network-heretics.com> <4A9225387F6E4CCB5BB1A018@JcK-HP8200.jck.com> <51BC8D66.9050000@network-heretics.com> <7ED5CCF8F4C22A4918928866@JcK-HP8200.jck.com> <51D6C1B0.7010004@helsinki.fi> <40BA98D4D3399F1F1597B425@[192.168.1.128]> <51DA956D.9070008@helsinki.fi> <51DB8396.7020802@stpeter.im> <51DBA50A.1060701@helsinki.fi> <51DC332C.4080309@stpeter.im> <51DDDAC9.60308@stpeter.im> <51DE5B5C.7070204@helsinki.fi> <51DF44F5.8080408@stpeter.im> In-Reply-To: <51DF44F5.8080408@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 04:08:30 -0000 On 7/11/13 5:51 PM, Peter Saint-Andre wrote: > On 7/11/13 1:14 AM, Juha Hakala wrote: >> Hello, >> >> A few suggestions: > > Thanks for the feedback. We're getting closer... > >> On 11.7.2013 1:06, Peter Saint-Andre wrote: >>> Here is some proposed text for 2141bis. >>> >>> SECTION 5 >>> >>> OLD >>> >>> URN = "urn" ":" NID ":" NSS >>> ; >>> ; the URI scheme ("urn") is case-insensitive >>> ; >>> NID = (alphanum) 0*30(ldh) (alphanum) >>> ; >>> ; alphanum is defined in RFC 3986 >>> ; >>> ldh = alphanum / "-" >>> NSS = 1*(pchar) >>> ; >>> ; pchar is defined in RFC 3986 >>> ; >>> >>> NEW >>> >>> >>> namestring = assigned-name [ "?" query ] [ "#" fragment ] >>> ; >>> ; query and fragment are defined in RFC 3986 >>> ; >>> assigned-name = "urn" ":" NID ":" NSS >>> ; >>> ; the URI scheme ("urn") is case-insensitive >>> ; >>> NID = (alphanum) 0*30(ldh) (alphanum) >>> ; >>> ; alphanum is defined in RFC 3986 >>> ; >>> ldh = alphanum / "-" >>> NSS = 1*(pchar) >>> ; >>> ; pchar is defined in RFC 3986 >>> ; >> Fine with me. Some (most?) query / fragment combinations would not make >> sense, but that doesn't need to be discussed here. > > Agreed. > >>> SECTION 5.3 (new section) >>> >>> 5.3. Query Component and Fragment Identifier Component >>> >>> The URI specification [RFC3986] allows a query component, a fragment >>> identifier component, or both after the path component of a URI, >>> where the character '?' is used as a separator to denote the >>> beginning of the query component and the character '#' is used as a >>> separator to denote the beginning of the fragment identifier >>> component. The original URN syntax specification [RFC2141] reserved >>> the '?' and '#' characters for future developments. This >>> specification aligns URN syntax with URI syntax by allowing the query >>> component and fragment identifier component after (not within) the >>> Namespace Specific String (NSS). >> I do not know how obvious things should be made. But you could add here >> something like this: >> >> In the URN context, query can be used for e.g. requesting a resolution >> service. Fragment can be used for distinguishing a particular location >> within or a segment of a resource identified by the NSS. >>> However, this specification does >>> not define the applicability and semantics of the query component or >>> the fragment identifier component in URNs. Additional specifications >>> might establish these matters for URN-related services (such as >>> resolution) or for individual URN namespaces. In particular, methods >>> for distinguishing the component parts of resources named by URNs >>> within individual namespaces are the responsibility of specifications >>> for those namespaces (e.g., they might use URI fragment identifier >>> component syntax or some namespace-specific syntax). >> How about "responsibility of namespace registration requests and other >> specifications for those namespaces (e.g., they may use some >> namespace-specific syntax)."? >> >> Giving URI fragment identifier a prominent role here might confuse >> people and make them believe that fragments do identify something after >> all. > > Here is revised text: > > ### > > 5.3. Query Component and Fragment Identifier Component > > The URI specification [RFC3986] allows a query component, a fragment > identifier component, or both after the path component of a URI, > where the character '?' is used as a separator to denote the > beginning of the query component and the character '#' is used as a > separator to denote the beginning of the fragment identifier > component. The original URN syntax specification [RFC2141] reserved > the '?' and '#' characters for future developments. This > specification aligns URN syntax with URI syntax by allowing the query > component and fragment identifier component after (not within) the > Namespace Specific String (NSS). > > This specification does not define the applicability and semantics of > the query component or the fragment identifier component in URNs. > Additional specifications might establish these matters for URN- > related services (such as resolution) or for individual URN > namespaces. For example, it is possible that the query component > might be used in requests to URN resolution services, or that the URI > fragment component might be used to distinguish the component parts > of resources named by URNs. However, defining such usage is left to > specifications for URN resolution services, namespace registration > requests and specifications for individual namespaces (which might > use some namespace-specific syntax instead of the URI fragment > component), and other appropriate documentation (such as policy > documents governing the management of a given URN namespace). > > ### > >> Is it necessary to mention here or somewhere else in 2141bis that the >> identifier assignment can be a managed process (depending on the >> namespace), but anyone can add a query and / or fragment to basically >> any URN once the identifier has been assigned. > > Perhaps. I'll look at this further a bit later tonight and propose some > more text. Further tweaking. Thanks to Juha for the suggestions. ### The URI specification [RFC3986] allows a query component, a fragment identifier component, or both after the path component of a URI, where the character '?' is used as a separator to denote the beginning of the query component and the character '#' is used as a separator to denote the beginning of the fragment identifier component. The original URN syntax specification [RFC2141] reserved the '?' and '#' characters for future developments. This specification aligns URN syntax with URI syntax by allowing the query component and fragment identifier component after (not within) the Namespace Specific String (NSS). This specification does not define the applicability and semantics of the query component or the fragment identifier component in URNs. Additional specifications might establish these matters for URN- related services (such as resolution) or for individual URN namespaces. For example, it is possible that the query component might be used in requests to URN resolution services, or that the fragment identifier component might be used to distinguish the component parts of resources named by URNs. However, defining such usage is left to specifications for URN resolution services, namespace registration requests and specifications for individual namespaces (which might use some namespace-specific syntax instead of the URI fragment identifier component), and other appropriate documentation (such as policy documents governing the management of a given URN namespace). Although URN assignment is often a managed process (see [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]), the query component or fragment identifier component can be appended after the NSS once a URN has been assigned in accordance with the rules for a given namespace. ### Peter -- Peter Saint-Andre https://stpeter.im/ From internet-drafts@ietf.org Fri Jul 12 11:07:36 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CA821F9F28; Fri, 12 Jul 2013 11:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoyJlacJcnaQ; Fri, 12 Jul 2013 11:07:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C4421F9F48; Fri, 12 Jul 2013 11:07:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130712180730.3860.89529.idtracker@ietfa.amsl.com> Date: Fri, 12 Jul 2013 11:07:30 -0700 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 18:07:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Uniform Resource Names, Revised Working G= roup of the IETF. Title : Uniform Resource Name (URN) Namespace Definition Mechani= sms Author(s) : Peter Saint-Andre Leslie Daigle Dirk-Willem van Gulik Renato Iannella Patrick Faltstrom Filename : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-06.txt Pages : 17 Date : 2013-07-12 Abstract: This document supplements the Uniform Resource Name (URN) syntax specification by defining the concept of a URN namespace, as well as mechanisms for defining and registering such namespaces. This document obsoletes RFC 3406. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc3406bis-urn-ns-reg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-urnbis-rfc3406bis-urn-ns-reg-= 06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Jul 12 11:07:37 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA6421F9F48; Fri, 12 Jul 2013 11:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyBwg6Mj6+Vw; Fri, 12 Jul 2013 11:07:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C875121F9F53; Fri, 12 Jul 2013 11:07:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130712180730.5169.66631.idtracker@ietfa.amsl.com> Date: Fri, 12 Jul 2013 11:07:30 -0700 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-05.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 18:07:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Uniform Resource Names, Revised Working G= roup of the IETF. Title : Uniform Resource Name (URN) Syntax Author(s) : Peter Saint-Andre Ryan Moats Filename : draft-ietf-urnbis-rfc2141bis-urn-05.txt Pages : 9 Date : 2013-07-12 Abstract: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is intended to serve as a persistent, location-independent resource identifier. This document defines the canonical syntax for URIs under the "urn" scheme, guidelines for URN namespaces, requirements for URN presentation and transmission, and methods for determining URN equivalence. This document obsoletes RFC 2141. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-urnbis-rfc2141bis-urn-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stpeter@stpeter.im Fri Jul 12 11:09:38 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB2111E8150 for ; Fri, 12 Jul 2013 11:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KS8piK8aXs2x for ; Fri, 12 Jul 2013 11:09:33 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C5E4E11E811E for ; Fri, 12 Jul 2013 11:09:32 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2228141414; Fri, 12 Jul 2013 12:10:45 -0600 (MDT) Message-ID: <51E04659.7060901@stpeter.im> Date: Fri, 12 Jul 2013 12:09:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "urn@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [urn] updated URNBIS I-Ds X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 18:09:38 -0000 I have updated 2141bis and 3406bis to the best of my ability, incorporating what I perceive as agreement based on list discussion. Naturally you might disagree with my reading of things, in which case please post to the list, preferably with proposed text. We discuss open issues at the IETF meeting in Berlin several weeks from now. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From juha.hakala@helsinki.fi Mon Jul 15 05:32:49 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E2111E80F0 for ; Mon, 15 Jul 2013 05:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.088 X-Spam-Level: X-Spam-Status: No, score=-6.088 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPwh+U-0Pt7m for ; Mon, 15 Jul 2013 05:32:43 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0185011E80EE for ; Mon, 15 Jul 2013 05:32:33 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r6FCWUwx025992 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Mon, 15 Jul 2013 15:32:32 +0300 Message-ID: <51E3EBDE.6040906@helsinki.fi> Date: Mon, 15 Jul 2013 15:32:30 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: urn@ietf.org References: <51E04659.7060901@stpeter.im> In-Reply-To: <51E04659.7060901@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] updated URNBIS I-Ds X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 12:32:49 -0000 Hello Peter, On 12.7.2013 21:09, Peter Saint-Andre wrote: > I have updated 2141bis and 3406bis to the best of my ability, > incorporating what I perceive as agreement based on list discussion. Thank you for doing this; incorporating query and fragment into the URN syntax is an important step forward. > Naturally you might disagree with my reading of things, in which case > please post to the list, preferably with proposed text. We discuss open > issues at the IETF meeting in Berlin several weeks from now. I have comments to chapters 6 and 7 (lexical and functional equivalence in URNs). RFC 3986 does not make the difference between lexical and functional equivalence? Do we need to? If we do (and I hope so), we need to clarify the text. The present version, parts of which come from RFC 2141, is a bit obscure since it does not refer to RFC 3986. And there are some bits which are IMO incorrect. Assuming that we do not throw away functional equivalence, we should first say that what we call lexical equivalence is the same as equivalence specified in chapter 6.1 of RFC 3986. That is, we compare two URN strings to see if they are the same, and ignore fragment and query in the process. The resource itself is not retrieved; the principles for comparison should be (more or less) the same as those applied in RFC 3986. The current I-D does not make it clear enough what we mean by functional equivalence. RFC 2141 says that two URNs are functionally equivalent if they are identical within a namespace. We have done away that unfortunate statement in Peter's draft; if two URN strings are identical within a namespace (as specified by RFC 3986) they must be lexically equivalent as well, and the other way around. A namespace cannot apply syntax that differs from RFC 3986. Specified like this, functional equivalence does not seem to bring much added value. But given the nature of the URNs, we may say that analyzing functional equivalence involves retrieval of the resource. Then two URNs are functionally equivalent if they resolve to the "same thing". Specified like this, we get some interesting differences between functional and lexical equivalence. First, two URNs from different namespaces will never be lexically equivalent but they can be functionally equivalent iff the outcome of the resolution process is the same. Second, these two URNs urn:example:a123,456?s=U2C urn:example:a123,456?s=U2L are lexically but not functionally equivalent. Lexical equivalence ignores the query since we are just comparing the identifier strings. But the outcomes of the resolution processes will differ. In the first example it is the resource itself, in the latter a URL from which the resource can be retrieved. Analyzing functional equivalence makes sense for URNs, since we have a limited set of well specified services. I am in favour of keeping the functional equivalence chapter, but in an edited form. It is definitely not right to say that functional equivalence can be determined within a given namespace since (as was pointed out in a previous version of the RFC2141bis) the same resource may receive URNs from multiple namespaces. Juha > > Thanks! > > Peter > -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 From stpeter@stpeter.im Mon Jul 15 14:07:15 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A3F11E816E for ; Mon, 15 Jul 2013 14:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-WjESXJvzPB for ; Mon, 15 Jul 2013 14:07:10 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EC43C11E818E for ; Mon, 15 Jul 2013 14:07:06 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B6FF341442; Mon, 15 Jul 2013 15:08:29 -0600 (MDT) Message-ID: <51E46473.4060700@stpeter.im> Date: Mon, 15 Jul 2013 15:06:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Juha Hakala References: <51E04659.7060901@stpeter.im> <51E3EBDE.6040906@helsinki.fi> In-Reply-To: <51E3EBDE.6040906@helsinki.fi> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] updated URNBIS I-Ds X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:07:16 -0000 On 7/15/13 6:32 AM, Juha Hakala wrote: > Hello Peter, > > On 12.7.2013 21:09, Peter Saint-Andre wrote: >> I have updated 2141bis and 3406bis to the best of my ability, >> incorporating what I perceive as agreement based on list discussion. > Thank you for doing this; incorporating query and fragment into the URN > syntax is an important step forward. >> Naturally you might disagree with my reading of things, in which case >> please post to the list, preferably with proposed text. We discuss open >> issues at the IETF meeting in Berlin several weeks from now. > I have comments to chapters 6 and 7 (lexical and functional equivalence > in URNs). > > RFC 3986 does not make the difference between lexical and functional > equivalence? Section 6.1 of RFC 3986 does state: Because URIs exist to identify resources, presumably they should be considered equivalent when they identify the same resource. However, this definition of equivalence is not of much practical use, as there is no way for an implementation to compare two resources unless it has full knowledge or control of them. For this reason, determination of equivalence or difference of URIs is based on string comparison, perhaps augmented by reference to additional rules provided by URI scheme definitions. We use the terms "different" and "equivalent" to describe the possible outcomes of such comparisons, but there are many application-dependent versions of equivalence. It seems to me that "considered equivalent when they identify the same resource" is "functionally equivalent", whereas "determination of equivalence ... based on string comparison" is "lexically equivalent". I was trying not to change RFC 2141 very much, which is why I left in the phrase "lexically equivalent", but I would be happy to remove the word 'lexically' throughout 2141bis. > Do we need to? I don't think we need to. > If we do (and I hope so), we need to clarify the text. The present > version, parts of which come from RFC 2141, is a bit obscure since it > does not refer to RFC 3986. And there are some bits which are IMO > incorrect. > > Assuming that we do not throw away functional equivalence, As RFC 3986 points out, the concept of functional equivalence is not really actionable in practice, so I think it would be best to remove it. > we should > first say that what we call lexical equivalence is the same as > equivalence specified in chapter 6.1 of RFC 3986. That is, we compare > two URN strings to see if they are the same, and ignore fragment and > query in the process. The resource itself is not retrieved; the > principles for comparison should be (more or less) the same as those > applied in RFC 3986. I see no reason why they would be different at all. We simply need to say which methods of equivalence checking are applied. > The current I-D does not make it clear enough what we mean by functional > equivalence. RFC 2141 says that two URNs are functionally equivalent if > they are identical within a namespace. We have done away that > unfortunate statement in Peter's draft; if two URN strings are identical > within a namespace (as specified by RFC 3986) they must be lexically > equivalent as well, and the other way around. A namespace cannot apply > syntax that differs from RFC 3986. > > Specified like this, functional equivalence does not seem to bring much > added value. But given the nature of the URNs, we may say that analyzing > functional equivalence involves retrieval of the resource. Then two URNs > are functionally equivalent if they resolve to the "same thing". This is what RFC 3986 says, too. But why is functional equivalence useful? And, from the perspective of the document, why is it important and valuable to specify what functional equivalence might mean? > Specified like this, we get some interesting differences between > functional and lexical equivalence. First, two URNs from different > namespaces will never be lexically equivalent but they can be > functionally equivalent iff the outcome of the resolution process is the > same. IMHO that is analogous to the following sentences from RFC 3986: Even though it is possible to determine that two URIs are equivalent, URI comparison is not sufficient to determine whether two URIs identify different resources. For example, an owner of two different domain names could decide to serve the same resource from both, resulting in two different URIs. > Second, these two URNs > > urn:example:a123,456?s=U2C > urn:example:a123,456?s=U2L > > are lexically but not functionally equivalent. Lexical equivalence > ignores the query since we are just comparing the identifier strings. > But the outcomes of the resolution processes will differ. In the first > example it is the resource itself, in the latter a URL from which the > resource can be retrieved. Is that fundamentally different from general URI equivalence checking? > Analyzing functional equivalence makes sense for URNs, since we have a > limited set of well specified services. I am in favour of keeping the > functional equivalence chapter, but in an edited form. It is definitely > not right to say that functional equivalence can be determined within a > given namespace since (as was pointed out in a previous version of the > RFC2141bis) the same resource may receive URNs from multiple namespaces. And, following the domain name example above, it's possible that URNs from different namespaces could identity the same resource. However, I just don't think it's useful to describe this in 2141bis and I propose that we drop all mention of functional equivalence. I think RFC 3986 got this right. Peter -- Peter Saint-Andre https://stpeter.im/ From juha.hakala@helsinki.fi Mon Jul 15 23:09:46 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AE721E81BA for ; Mon, 15 Jul 2013 23:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.545 X-Spam-Level: X-Spam-Status: No, score=-5.545 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJ0fJy-UDdYc for ; Mon, 15 Jul 2013 23:09:40 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 73CB421E81AB for ; Mon, 15 Jul 2013 23:09:40 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r6G69Za4029549 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 16 Jul 2013 09:09:36 +0300 Message-ID: <51E4E39F.2090303@helsinki.fi> Date: Tue, 16 Jul 2013 09:09:35 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Peter Saint-Andre References: <51E04659.7060901@stpeter.im> <51E3EBDE.6040906@helsinki.fi> <51E46473.4060700@stpeter.im> In-Reply-To: <51E46473.4060700@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] updated URNBIS I-Ds X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 06:09:46 -0000 Hello, On 16.7.2013 0:06, Peter Saint-Andre wrote: > Section 6.1 of RFC 3986 does state: > > Because URIs exist to identify resources, presumably they should be > considered equivalent when they identify the same resource. However, > this definition of equivalence is not of much practical use, as there > is no way for an implementation to compare two resources unless it > has full knowledge or control of them. This assumes that there are no applications which have full knowledge or control of resources. Applications in which persistent identifiers will be used, such as digital preservation systems and web archives, may not have "full knowledge or control" (whatever that means). However, it is a normal practice in these applications to calculate a checksum for all ingested documents in order to find out if a copy of the resource is already stored in the system. If a duplicate is found, and if the stored copy has another URN, then the system will know that these two URNs are functionally equivalent. > For this reason, > determination of equivalence or difference of URIs is based on string > comparison, perhaps augmented by reference to additional rules > provided by URI scheme definitions. We use the terms "different" and > "equivalent" to describe the possible outcomes of such comparisons, > but there are many application-dependent versions of equivalence. There is nothing application dependent in checking with e.g. MD5 if two files are identical. > > It seems to me that "considered equivalent when they identify the same > resource" is "functionally equivalent", whereas "determination of > equivalence ... based on string comparison" is "lexically equivalent". Yes. And we have means for checking both kind of equivalences. > I > was trying not to change RFC 2141 very much, which is why I left in the > phrase "lexically equivalent", but I would be happy to remove the word > 'lexically' throughout 2141bis. This is fine only if we consider just lexical equivalence in rfc2141bis. Be that as it may, we can / should remove some of the prose in chapter 6 of the I-D and just refer to RFC 3986 and especially to the comparison ladder (chapter 6.2). > As RFC 3986 points out, the concept of functional equivalence is not > really actionable in practice, so I think it would be best to remove it. There are two practical reasons for keeping it: 1. It is possible to give two or more URNs to the same resource. 2. We have applications which know / can check easily if two resources are identical (based on checksums). For practical reasons it is often important to know if two URNs are functionally equivalent. With digital archives and other preservation tools which have emerged mainly after RFC 3986 was written we have now practical methods for determining functional equivalence of URNs (and to some extent even URLs). > >> we should >> first say that what we call lexical equivalence is the same as >> equivalence specified in chapter 6.1 of RFC 3986. That is, we compare >> two URN strings to see if they are the same, and ignore fragment and >> query in the process. The resource itself is not retrieved; the >> principles for comparison should be (more or less) the same as those >> applied in RFC 3986. > I see no reason why they would be different at all. We simply need to > say which methods of equivalence checking are applied. I do. RFC 3986 says that fragment components (if any) should be excluded from the comparison, and that's fine. But URI Generic Syntax does not say anything about what to do with the query component. We have to make it clear that for URNs the query components should ignored when the lexical equivalence of two URNs is checked (but note that query components are essential in the evaluation of functional equivalence). > > Specified like this, functional equivalence does not seem to bring much > added value. But given the nature of the URNs, we may say that analyzing > functional equivalence involves retrieval of the resource. Then two URNs > are functionally equivalent if they resolve to the "same thing". > This is what RFC 3986 says, too. But why is functional equivalence > useful? And, from the perspective of the document, why is it important > and valuable to specify what functional equivalence might mean? The world has changed a bit since RFC 3986 was written. Determining functional equivalence is important since the same resource can receive multiple URNs. We can easily find out in e.g. web archives and digital long term preservation systems if this is the case. It is difficult to know how many duplicate URNs there will be. But there is a lot of overlap between the namespaces so we may have a lot of duplicates. For instance, a researcher may give a urn:uuid for a report, which in the national library's collection receives urn:nbn. The main difference between these URNs is that one is from a well managed namespace, the other is not. There will be even more overlap between different PID systems. Publishers give DOIs to scientific articles in their repositories, and national libraries will apply NBNs in order to manage resolution. If we specify functional equivalence and a simple method for determining it in rfc2141bis, the same principles can be applied by other PID systems as well. > >> Second, these two URNs >> >> urn:example:a123,456?s=U2C >> urn:example:a123,456?s=U2L >> >> are lexically but not functionally equivalent. Lexical equivalence >> ignores the query since we are just comparing the identifier strings. >> But the outcomes of the resolution processes will differ. In the first >> example it is the resource itself, in the latter a URL from which the >> resource can be retrieved. > Is that fundamentally different from general URI equivalence checking? Yes, because RFC 3986 does not tell what to do with the query component. It should be noted that our method of determining the functional equivalence of two URNs is not fully applicable to URIs in general. If a query can be anything it is not really possible / practical to determine functional equivalence. But if appropriate ways of using query have been nailed down in the service registry, it should be rather easy to check if two query components are identical. The analysis can be based on the URN string; there is no need to retrieve the resource. > >> Analyzing functional equivalence makes sense for URNs, since we have a >> limited set of well specified services. I am in favour of keeping the >> functional equivalence chapter, but in an edited form. It is definitely >> not right to say that functional equivalence can be determined within a >> given namespace since (as was pointed out in a previous version of the >> RFC2141bis) the same resource may receive URNs from multiple namespaces. > And, following the domain name example above, it's possible that URNs > from different namespaces could identity the same resource. Your logic is not quite correct here. The fact that the same resource may exist in two different places in the Internet has nothing to do with the duplicate identifier assignment. > > However, I just don't think it's useful to describe this in 2141bis and > I propose that we drop all mention of functional equivalence. I think > RFC 3986 got this right. What's in RFC 3986 is right, but we can and should extend the scope of RFC 3986 by telling what to do with query component and by providing a simple way of determining if two resources are identical and therefore providing some means for the evaluation of functional equivalence in practice. Juha > > Peter > -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 From duerst@it.aoyama.ac.jp Tue Jul 16 03:20:15 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B3221E81E4 for ; Tue, 16 Jul 2013 03:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.04 X-Spam-Level: X-Spam-Status: No, score=-101.04 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSkXH3ge9Fbu for ; Tue, 16 Jul 2013 03:20:09 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id CF41D11E8294 for ; Tue, 16 Jul 2013 03:20:08 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r6GAJopk021672; Tue, 16 Jul 2013 19:19:51 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 655c_71bc_3fa2eef6_ee01_11e2_83a6_001e6722eec2; Tue, 16 Jul 2013 19:19:49 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 64880BF535; Tue, 16 Jul 2013 19:18:01 +0900 (JST) Message-ID: <51E51E36.5050100@it.aoyama.ac.jp> Date: Tue, 16 Jul 2013 19:19:34 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <51E04659.7060901@stpeter.im> <51E3EBDE.6040906@helsinki.fi> <51E46473.4060700@stpeter.im> In-Reply-To: <51E46473.4060700@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] updated URNBIS I-Ds X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 10:20:15 -0000 I agree with Peter here. Let's just make a simple example. Assume that there are urn namespaces for individual issues of journals, and for 'last issue' of journals. (that may not be a terribly good example, but I hope it's good enough to show the point). For a journal that's published every month, a specific individual issue and the 'last issue' will be "functionally equivalent" for a month, but then cease to be functionally equivalent. That knowledge isn't available by lexical comparison (of course not), but it's also not available by dereferencing. Regards, Martin. On 2013/07/16 6:06, Peter Saint-Andre wrote: > On 7/15/13 6:32 AM, Juha Hakala wrote: >> Hello Peter, >> >> On 12.7.2013 21:09, Peter Saint-Andre wrote: >>> I have updated 2141bis and 3406bis to the best of my ability, >>> incorporating what I perceive as agreement based on list discussion. >> Thank you for doing this; incorporating query and fragment into the URN >> syntax is an important step forward. >>> Naturally you might disagree with my reading of things, in which case >>> please post to the list, preferably with proposed text. We discuss open >>> issues at the IETF meeting in Berlin several weeks from now. >> I have comments to chapters 6 and 7 (lexical and functional equivalence >> in URNs). >> >> RFC 3986 does not make the difference between lexical and functional >> equivalence? > > Section 6.1 of RFC 3986 does state: > > Because URIs exist to identify resources, presumably they should be > considered equivalent when they identify the same resource. However, > this definition of equivalence is not of much practical use, as there > is no way for an implementation to compare two resources unless it > has full knowledge or control of them. For this reason, > determination of equivalence or difference of URIs is based on string > comparison, perhaps augmented by reference to additional rules > provided by URI scheme definitions. We use the terms "different" and > "equivalent" to describe the possible outcomes of such comparisons, > but there are many application-dependent versions of equivalence. > > It seems to me that "considered equivalent when they identify the same > resource" is "functionally equivalent", whereas "determination of > equivalence ... based on string comparison" is "lexically equivalent". I > was trying not to change RFC 2141 very much, which is why I left in the > phrase "lexically equivalent", but I would be happy to remove the word > 'lexically' throughout 2141bis. > >> Do we need to? > > I don't think we need to. > >> If we do (and I hope so), we need to clarify the text. The present >> version, parts of which come from RFC 2141, is a bit obscure since it >> does not refer to RFC 3986. And there are some bits which are IMO >> incorrect. >> >> Assuming that we do not throw away functional equivalence, > > As RFC 3986 points out, the concept of functional equivalence is not > really actionable in practice, so I think it would be best to remove it. > >> we should >> first say that what we call lexical equivalence is the same as >> equivalence specified in chapter 6.1 of RFC 3986. That is, we compare >> two URN strings to see if they are the same, and ignore fragment and >> query in the process. The resource itself is not retrieved; the >> principles for comparison should be (more or less) the same as those >> applied in RFC 3986. > > I see no reason why they would be different at all. We simply need to > say which methods of equivalence checking are applied. > >> The current I-D does not make it clear enough what we mean by functional >> equivalence. RFC 2141 says that two URNs are functionally equivalent if >> they are identical within a namespace. We have done away that >> unfortunate statement in Peter's draft; if two URN strings are identical >> within a namespace (as specified by RFC 3986) they must be lexically >> equivalent as well, and the other way around. A namespace cannot apply >> syntax that differs from RFC 3986. >> >> Specified like this, functional equivalence does not seem to bring much >> added value. But given the nature of the URNs, we may say that analyzing >> functional equivalence involves retrieval of the resource. Then two URNs >> are functionally equivalent if they resolve to the "same thing". > > This is what RFC 3986 says, too. But why is functional equivalence > useful? And, from the perspective of the document, why is it important > and valuable to specify what functional equivalence might mean? > >> Specified like this, we get some interesting differences between >> functional and lexical equivalence. First, two URNs from different >> namespaces will never be lexically equivalent but they can be >> functionally equivalent iff the outcome of the resolution process is the >> same. > > IMHO that is analogous to the following sentences from RFC 3986: > > Even though it is possible to determine that two URIs are equivalent, > URI comparison is not sufficient to determine whether two URIs > identify different resources. For example, an owner of two different > domain names could decide to serve the same resource from both, > resulting in two different URIs. > >> Second, these two URNs >> >> urn:example:a123,456?s=U2C >> urn:example:a123,456?s=U2L >> >> are lexically but not functionally equivalent. Lexical equivalence >> ignores the query since we are just comparing the identifier strings. >> But the outcomes of the resolution processes will differ. In the first >> example it is the resource itself, in the latter a URL from which the >> resource can be retrieved. > > Is that fundamentally different from general URI equivalence checking? > >> Analyzing functional equivalence makes sense for URNs, since we have a >> limited set of well specified services. I am in favour of keeping the >> functional equivalence chapter, but in an edited form. It is definitely >> not right to say that functional equivalence can be determined within a >> given namespace since (as was pointed out in a previous version of the >> RFC2141bis) the same resource may receive URNs from multiple namespaces. > > And, following the domain name example above, it's possible that URNs > from different namespaces could identity the same resource. > > However, I just don't think it's useful to describe this in 2141bis and > I propose that we drop all mention of functional equivalence. I think > RFC 3986 got this right. > > Peter > From juha.hakala@helsinki.fi Tue Jul 16 04:59:22 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2674021E805F for ; Tue, 16 Jul 2013 04:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.38 X-Spam-Level: X-Spam-Status: No, score=-5.38 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVdOl5Fiu38X for ; Tue, 16 Jul 2013 04:59:16 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id F303C21E809A for ; Tue, 16 Jul 2013 04:59:15 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r6GBx2fl022885 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 16 Jul 2013 14:59:04 +0300 Message-ID: <51E53586.2070609@helsinki.fi> Date: Tue, 16 Jul 2013 14:59:02 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <51E04659.7060901@stpeter.im> <51E3EBDE.6040906@helsinki.fi> <51E46473.4060700@stpeter.im> <51E51E36.5050100@it.aoyama.ac.jp> In-Reply-To: <51E51E36.5050100@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: urn@ietf.org Subject: Re: [urn] updated URNBIS I-Ds X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 11:59:22 -0000 Hello, On 16.7.2013 13:19, "Martin J. Dürst" wrote: > I agree with Peter here. > > Let's just make a simple example. Assume that there are urn namespaces > for individual issues of journals, and for 'last issue' of journals. > (that may not be a terribly good example, but I hope it's good enough > to show the point). All kinds of examples can of course be made, both in favour or against the usage of functional equivalence. But the value of these examples is dependent on how much they have to do with the real life. I hope that nobody is assigning URNs or other persistent identifiers to anything so ephemeral as the last issue of a journal. Libraries and publishers certainly don't; we use ISSNs for serial publications and DOIs, URN:NBNs etc. to the journal issues and articles. If an article has both DOI and URN:NBN these two identifiers are and will remain functionally equivalent. There are cases when it is necessary to keep track on & provide access to updated versions of a resource. W3C approach is to make the latest version available in the same address, such as http://www.w3.org/TR/rdf-syntax-grammar/ for the latest version of RDF/XML syntax specification. Library approach would be to assign persistent URN to the immaterial work, and then link the different manifestations and versions of the work to the work level metadata record. Our manifestation identifier oriented URN namespaces such as ISBN or NBN do not allow the practice of re-using the same identifier for successive versions of the same resource. All the best, Juha > > For a journal that's published every month, a specific individual > issue and the 'last issue' will be "functionally equivalent" for a > month, but then cease to be functionally equivalent. That knowledge > isn't available by lexical comparison (of course not), but it's also > not available by dereferencing. > > Regards, Martin. > > On 2013/07/16 6:06, Peter Saint-Andre wrote: >> On 7/15/13 6:32 AM, Juha Hakala wrote: >>> Hello Peter, >>> >>> On 12.7.2013 21:09, Peter Saint-Andre wrote: >>>> I have updated 2141bis and 3406bis to the best of my ability, >>>> incorporating what I perceive as agreement based on list discussion. >>> Thank you for doing this; incorporating query and fragment into the URN >>> syntax is an important step forward. >>>> Naturally you might disagree with my reading of things, in which case >>>> please post to the list, preferably with proposed text. We discuss >>>> open >>>> issues at the IETF meeting in Berlin several weeks from now. >>> I have comments to chapters 6 and 7 (lexical and functional equivalence >>> in URNs). >>> >>> RFC 3986 does not make the difference between lexical and functional >>> equivalence? >> >> Section 6.1 of RFC 3986 does state: >> >> Because URIs exist to identify resources, presumably they should be >> considered equivalent when they identify the same resource. However, >> this definition of equivalence is not of much practical use, as >> there >> is no way for an implementation to compare two resources unless it >> has full knowledge or control of them. For this reason, >> determination of equivalence or difference of URIs is based on >> string >> comparison, perhaps augmented by reference to additional rules >> provided by URI scheme definitions. We use the terms "different" >> and >> "equivalent" to describe the possible outcomes of such comparisons, >> but there are many application-dependent versions of equivalence. >> >> It seems to me that "considered equivalent when they identify the same >> resource" is "functionally equivalent", whereas "determination of >> equivalence ... based on string comparison" is "lexically equivalent". I >> was trying not to change RFC 2141 very much, which is why I left in the >> phrase "lexically equivalent", but I would be happy to remove the word >> 'lexically' throughout 2141bis. >> >>> Do we need to? >> >> I don't think we need to. >> >>> If we do (and I hope so), we need to clarify the text. The present >>> version, parts of which come from RFC 2141, is a bit obscure since it >>> does not refer to RFC 3986. And there are some bits which are IMO >>> incorrect. >>> >>> Assuming that we do not throw away functional equivalence, >> >> As RFC 3986 points out, the concept of functional equivalence is not >> really actionable in practice, so I think it would be best to remove it. >> >>> we should >>> first say that what we call lexical equivalence is the same as >>> equivalence specified in chapter 6.1 of RFC 3986. That is, we compare >>> two URN strings to see if they are the same, and ignore fragment and >>> query in the process. The resource itself is not retrieved; the >>> principles for comparison should be (more or less) the same as those >>> applied in RFC 3986. >> >> I see no reason why they would be different at all. We simply need to >> say which methods of equivalence checking are applied. >> >>> The current I-D does not make it clear enough what we mean by >>> functional >>> equivalence. RFC 2141 says that two URNs are functionally equivalent if >>> they are identical within a namespace. We have done away that >>> unfortunate statement in Peter's draft; if two URN strings are >>> identical >>> within a namespace (as specified by RFC 3986) they must be lexically >>> equivalent as well, and the other way around. A namespace cannot apply >>> syntax that differs from RFC 3986. >>> >>> Specified like this, functional equivalence does not seem to bring much >>> added value. But given the nature of the URNs, we may say that >>> analyzing >>> functional equivalence involves retrieval of the resource. Then two >>> URNs >>> are functionally equivalent if they resolve to the "same thing". >> >> This is what RFC 3986 says, too. But why is functional equivalence >> useful? And, from the perspective of the document, why is it important >> and valuable to specify what functional equivalence might mean? >> >>> Specified like this, we get some interesting differences between >>> functional and lexical equivalence. First, two URNs from different >>> namespaces will never be lexically equivalent but they can be >>> functionally equivalent iff the outcome of the resolution process is >>> the >>> same. >> >> IMHO that is analogous to the following sentences from RFC 3986: >> >> Even though it is possible to determine that two URIs are >> equivalent, >> URI comparison is not sufficient to determine whether two URIs >> identify different resources. For example, an owner of two >> different >> domain names could decide to serve the same resource from both, >> resulting in two different URIs. >> >>> Second, these two URNs >>> >>> urn:example:a123,456?s=U2C >>> urn:example:a123,456?s=U2L >>> >>> are lexically but not functionally equivalent. Lexical equivalence >>> ignores the query since we are just comparing the identifier strings. >>> But the outcomes of the resolution processes will differ. In the first >>> example it is the resource itself, in the latter a URL from which the >>> resource can be retrieved. >> >> Is that fundamentally different from general URI equivalence checking? >> >>> Analyzing functional equivalence makes sense for URNs, since we have a >>> limited set of well specified services. I am in favour of keeping the >>> functional equivalence chapter, but in an edited form. It is definitely >>> not right to say that functional equivalence can be determined within a >>> given namespace since (as was pointed out in a previous version of the >>> RFC2141bis) the same resource may receive URNs from multiple >>> namespaces. >> >> And, following the domain name example above, it's possible that URNs >> from different namespaces could identity the same resource. >> >> However, I just don't think it's useful to describe this in 2141bis and >> I propose that we drop all mention of functional equivalence. I think >> RFC 3986 got this right. >> >> Peter >> -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 From sm@resistor.net Tue Jul 16 10:21:20 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890B321E808B for ; Tue, 16 Jul 2013 10:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNpmH2Q7qt1x for ; Tue, 16 Jul 2013 10:21:19 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B86AD21E8082 for ; Tue, 16 Jul 2013 10:21:19 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6GHL26l012733; Tue, 16 Jul 2013 10:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373995269; bh=mcuzoWdsYavQsp15BXSq5MFgGKgHRVMvU3uxZIZvU9U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Q7vKVvteHZSiDaLnlbF0TLuVWfPAhd+0hkI+ObqlYYXQa7E6iPONQKHiG2Ee/mluc oXmaB3dGs+F1c827m++Yl32oWlINkuTgNFizl050q5Vz01y/X4zY/Eb9uMvfdZE32i eIGwa1PxQdQmN1b1DJqrfB22P8EcZXUE8wxHvqvE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1373995269; i=@resistor.net; bh=mcuzoWdsYavQsp15BXSq5MFgGKgHRVMvU3uxZIZvU9U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=p4kwrASybT7ww3fuSTjn0nY5YmcM+mua+oo92VuiZyUwl+cSXUYYMnyWnWZcktxdm bHpXgifcQA2m7adpX5MrSK1LHRR/uPJtcqxgS6T1RyTmEsFm93dJia/Aot7cWM+SiH KHyoKJi/hcy+q/Vt64I3qbSmbrxMQ0R1OsaVaLM0= Message-Id: <6.2.5.6.2.20130716100602.0b561948@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 16 Jul 2013 10:18:24 -0700 To: Juha Hakala , Peter Saint-Andre From: SM In-Reply-To: <51E4E39F.2090303@helsinki.fi> References: <51E04659.7060901@stpeter.im> <51E3EBDE.6040906@helsinki.fi> <51E46473.4060700@stpeter.im> <51E4E39F.2090303@helsinki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: urn@ietf.org Subject: Re: [urn] updated URNBIS I-Ds X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 17:21:20 -0000 Hu Juha, Peter, At 23:09 15-07-2013, Juha Hakala wrote: >On 16.7.2013 0:06, Peter Saint-Andre wrote: >>Section 6.1 of RFC 3986 does state: >> >> Because URIs exist to identify resources, presumably they should be >> considered equivalent when they identify the same resource. However, >> this definition of equivalence is not of much practical use, as there >> is no way for an implementation to compare two resources unless it >> has full knowledge or control of them. >This assumes that there are no applications which have full >knowledge or control of resources. Applications in which persistent >identifiers will be used, such as digital preservation systems and >web archives, may not have "full knowledge or control" (whatever >that means). However, it is a normal practice in these applications >to calculate a checksum for all ingested documents in order to find >out if a copy of the resource is already stored in the system. If a >duplicate is found, and if the stored copy has another URN, then the >system will know that these two URNs are functionally equivalent. >>For this reason, >> determination of equivalence or difference of URIs is based on string >> comparison, perhaps augmented by reference to additional rules >> provided by URI scheme definitions. We use the terms "different" and >> "equivalent" to describe the possible outcomes of such comparisons, >> but there are many application-dependent versions of equivalence. >There is nothing application dependent in checking with e.g. MD5 if >two files are identical. It seems to me that you are looking at the problem from different angles. I would describe it as conceptual differences instead of differences about terminology. It might be about trying to fit URNs into what the IETF is familiar with versus having a common understanding of URNs and then work things out from there. Regards, -sm From stpeter@stpeter.im Tue Jul 16 11:31:16 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5659821E8095 for ; Tue, 16 Jul 2013 11:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh7vhCPLQ4aR for ; Tue, 16 Jul 2013 11:31:11 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3492221E8064 for ; Tue, 16 Jul 2013 11:31:11 -0700 (PDT) Received: from sjc-vpn3-1406.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 775354145F; Tue, 16 Jul 2013 12:32:36 -0600 (MDT) Message-ID: <51E5916B.5020101@stpeter.im> Date: Tue, 16 Jul 2013 12:31:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: SM References: <51E04659.7060901@stpeter.im> <51E3EBDE.6040906@helsinki.fi> <51E46473.4060700@stpeter.im> <51E4E39F.2090303@helsinki.fi> <6.2.5.6.2.20130716100602.0b561948@resistor.net> In-Reply-To: <6.2.5.6.2.20130716100602.0b561948@resistor.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] updated URNBIS I-Ds X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 18:31:16 -0000 On 7/16/13 11:18 AM, SM wrote: > Hu Juha, Peter, > At 23:09 15-07-2013, Juha Hakala wrote: >> On 16.7.2013 0:06, Peter Saint-Andre wrote: >>> Section 6.1 of RFC 3986 does state: >>> >>> Because URIs exist to identify resources, presumably they should be >>> considered equivalent when they identify the same resource. >>> However, >>> this definition of equivalence is not of much practical use, as >>> there >>> is no way for an implementation to compare two resources unless it >>> has full knowledge or control of them. >> This assumes that there are no applications which have full knowledge >> or control of resources. Applications in which persistent identifiers >> will be used, such as digital preservation systems and web archives, >> may not have "full knowledge or control" (whatever that means). >> However, it is a normal practice in these applications to calculate a >> checksum for all ingested documents in order to find out if a copy of >> the resource is already stored in the system. If a duplicate is found, >> and if the stored copy has another URN, then the system will know that >> these two URNs are functionally equivalent. >>> For this reason, >>> determination of equivalence or difference of URIs is based on >>> string >>> comparison, perhaps augmented by reference to additional rules >>> provided by URI scheme definitions. We use the terms "different" >>> and >>> "equivalent" to describe the possible outcomes of such comparisons, >>> but there are many application-dependent versions of equivalence. >> There is nothing application dependent in checking with e.g. MD5 if >> two files are identical. > > It seems to me that you are looking at the problem from different > angles. I would describe it as conceptual differences instead of > differences about terminology. It might be about trying to fit URNs > into what the IETF is familiar with versus having a common understanding > of URNs and then work things out from there. Hi SM, That may be. My point is that if application developers wish to go searching for functional equivalence, they are free to do so. However, we don't need to say anything about that in 2141bis, just as RFC 3986 didn't try to define the possible ways to determine functional equivalence for URIs in general. What would be the purpose of this text? What would break if we don't include it? Remember, 2141bis is about URN syntax, and it seems to me that syntactically all we can talk about is lexical equivalence. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Jul 16 11:34:16 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E5121F991F for ; Tue, 16 Jul 2013 11:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9B2g2CSKzOSR for ; Tue, 16 Jul 2013 11:34:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E152B21F964C for ; Tue, 16 Jul 2013 11:34:04 -0700 (PDT) Received: from sjc-vpn3-1406.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 15E484145F; Tue, 16 Jul 2013 12:35:30 -0600 (MDT) Message-ID: <51E5921A.4070303@stpeter.im> Date: Tue, 16 Jul 2013 12:34:02 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: SM References: <51E04659.7060901@stpeter.im> <51E3EBDE.6040906@helsinki.fi> <51E46473.4060700@stpeter.im> <51E4E39F.2090303@helsinki.fi> <6.2.5.6.2.20130716100602.0b561948@resistor.net> <51E5916B.5020101@stpeter.im> In-Reply-To: <51E5916B.5020101@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] updated URNBIS I-Ds X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 18:34:16 -0000 On 7/16/13 12:31 PM, Peter Saint-Andre wrote: > On 7/16/13 11:18 AM, SM wrote: >> Hu Juha, Peter, >> At 23:09 15-07-2013, Juha Hakala wrote: >>> On 16.7.2013 0:06, Peter Saint-Andre wrote: >>>> Section 6.1 of RFC 3986 does state: >>>> >>>> Because URIs exist to identify resources, presumably they should be >>>> considered equivalent when they identify the same resource. >>>> However, >>>> this definition of equivalence is not of much practical use, as >>>> there >>>> is no way for an implementation to compare two resources unless it >>>> has full knowledge or control of them. >>> This assumes that there are no applications which have full knowledge >>> or control of resources. Applications in which persistent identifiers >>> will be used, such as digital preservation systems and web archives, >>> may not have "full knowledge or control" (whatever that means). >>> However, it is a normal practice in these applications to calculate a >>> checksum for all ingested documents in order to find out if a copy of >>> the resource is already stored in the system. If a duplicate is found, >>> and if the stored copy has another URN, then the system will know that >>> these two URNs are functionally equivalent. >>>> For this reason, >>>> determination of equivalence or difference of URIs is based on >>>> string >>>> comparison, perhaps augmented by reference to additional rules >>>> provided by URI scheme definitions. We use the terms "different" >>>> and >>>> "equivalent" to describe the possible outcomes of such comparisons, >>>> but there are many application-dependent versions of equivalence. >>> There is nothing application dependent in checking with e.g. MD5 if >>> two files are identical. >> >> It seems to me that you are looking at the problem from different >> angles. I would describe it as conceptual differences instead of >> differences about terminology. It might be about trying to fit URNs >> into what the IETF is familiar with versus having a common understanding >> of URNs and then work things out from there. > > Hi SM, > > That may be. My point is that if application developers wish to go > searching for functional equivalence, they are free to do so. However, > we don't need to say anything about that in 2141bis, just as RFC 3986 > didn't try to define the possible ways to determine functional > equivalence for URIs in general. What would be the purpose of this text? > What would break if we don't include it? Remember, 2141bis is about URN > syntax, and it seems to me that syntactically all we can talk about is > lexical equivalence. Indeed, I would go farther and assert that we don't need the current text on functional equivalence (Section 7) -- what's said in RFC 3986 is enough and we cite that normatively. Peter -- Peter Saint-Andre https://stpeter.im/ From sm@resistor.net Tue Jul 16 14:06:11 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AF821F9E3B for ; Tue, 16 Jul 2013 14:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+lTjqbTFbpD for ; Tue, 16 Jul 2013 14:06:10 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0B021F9CE8 for ; Tue, 16 Jul 2013 14:06:01 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6GL5g0i029402; Tue, 16 Jul 2013 14:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1374008748; bh=uSMpTpp9PZ0zCJRb88AYbC5mmUWm+C2ocvcUYv+NLgU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3Z2wDJbvfx6p+l3jC6k6DPQCYqe1O0LP2IZL0gZhfbfwpToy0v80E2UstYQ85vlrf O0zcy0Efl85PvRdq44C6AghfebyK4R41mYPQvGkBldpnroeRHaTv3RQiqRWIpnjh/a fCB1cUUSCRvtF+YWuIZvcuQBd1iRwbO4/cz1mDwE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1374008748; i=@resistor.net; bh=uSMpTpp9PZ0zCJRb88AYbC5mmUWm+C2ocvcUYv+NLgU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=B+xOOVGaQQagvTocH9k2o6SRRlQqc5YmSWr4YVrqKtNPVrybzmLPgrjzzGCiIItFY wawSUG9ThCqfeAZw6Jo+qXYjaIIzYyaGpdbvLnbzZEYGyooPyage23qIB4b7fzsv2L P1GKKkv33guwgj0IS2EVKIi0V9e6zS5vgeV1Oh7E= Message-Id: <6.2.5.6.2.20130716131044.0b6abfd8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 16 Jul 2013 13:52:26 -0700 To: Peter Saint-Andre From: SM In-Reply-To: <51E5921A.4070303@stpeter.im> References: <51E04659.7060901@stpeter.im> <51E3EBDE.6040906@helsinki.fi> <51E46473.4060700@stpeter.im> <51E4E39F.2090303@helsinki.fi> <6.2.5.6.2.20130716100602.0b561948@resistor.net> <51E5916B.5020101@stpeter.im> <51E5921A.4070303@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: urn@ietf.org Subject: Re: [urn] updated URNBIS I-Ds X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 21:06:11 -0000 Hi Peter, At 11:34 16-07-2013, Peter Saint-Andre wrote: > > That may be. My point is that if application developers wish to go > > searching for functional equivalence, they are free to do so. However, > > we don't need to say anything about that in 2141bis, just as RFC 3986 > > didn't try to define the possible ways to determine functional > > equivalence for URIs in general. What would be the purpose of this text? > > What would break if we don't include it? Remember, 2141bis is about URN > > syntax, and it seems to me that syntactically all we can talk about is > > lexical equivalence. > >Indeed, I would go farther and assert that we don't need the current >text on functional equivalence (Section 7) -- what's said in RFC 3986 is >enough and we cite that normatively. I'll apologize beforehand for the IETF perspective of my comment. RFC 3986 is already cited normatively. The draft can avoid getting into that. The developer still has the ability to go and search for equivalence if he or she wishes. I think that the angle to look into is what would break if we don't include the text. If I read Juha's message correctly it does not break anything. Regards, -sm From stpeter@stpeter.im Tue Jul 16 14:09:14 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6FA21F9EEB for ; Tue, 16 Jul 2013 14:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmbJ6jsg6oGc for ; Tue, 16 Jul 2013 14:08:57 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE2F21F9F50 for ; Tue, 16 Jul 2013 14:08:57 -0700 (PDT) Received: from sjc-vpn6-1669.cisco.com (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D1C2541464; Tue, 16 Jul 2013 15:10:23 -0600 (MDT) Message-ID: <51E5B667.1040005@stpeter.im> Date: Tue, 16 Jul 2013 15:08:55 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: SM References: <51E04659.7060901@stpeter.im> <51E3EBDE.6040906@helsinki.fi> <51E46473.4060700@stpeter.im> <51E4E39F.2090303@helsinki.fi> <6.2.5.6.2.20130716100602.0b561948@resistor.net> <51E5916B.5020101@stpeter.im> <51E5921A.4070303@stpeter.im> <6.2.5.6.2.20130716131044.0b6abfd8@resistor.net> In-Reply-To: <6.2.5.6.2.20130716131044.0b6abfd8@resistor.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] updated URNBIS I-Ds X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 21:09:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/16/13 2:52 PM, SM wrote: > Hi Peter, At 11:34 16-07-2013, Peter Saint-Andre wrote: >>> That may be. My point is that if application developers wish to >>> go searching for functional equivalence, they are free to do >>> so. However, we don't need to say anything about that in >>> 2141bis, just as RFC 3986 didn't try to define the possible >>> ways to determine functional equivalence for URIs in general. >>> What would be the purpose of this >> text? >>> What would break if we don't include it? Remember, 2141bis is >>> about URN syntax, and it seems to me that syntactically all we >>> can talk about is lexical equivalence. >> >> Indeed, I would go farther and assert that we don't need the >> current text on functional equivalence (Section 7) -- what's said >> in RFC 3986 is enough and we cite that normatively. > > I'll apologize beforehand for the IETF perspective of my comment. > > RFC 3986 is already cited normatively. The draft can avoid getting > into that. The developer still has the ability to go and search > for equivalence if he or she wishes. I think that the angle to > look into is what would break if we don't include the text. If I > read Juha's message correctly it does not break anything. I'd agree. My philosophy of spec-writing has always been, if it's not mentioned in the spec then you are free to do something interesting and creative to solve whatever problems you need to solve in the real world. Searching for functional equivalence seems to be one of those cases. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR5bZmAAoJEOoGpJErxa2pK5UP/1u1dLJuHmp/AzDWWGqd803a G9qX6MPBDfDss6LSpfuJzttszhg0pByvH0X2vaYUeasVZ8pYt7TVO8x9l4xT3qDn 9kO0K1dVmGXP0bTY/SBCrEtycLTR7Zz7MVZP7y/FDIK2TGoMjZvd0dd11SKT62rL m2PsJh/14LcwUBkgnAt8H9ozIPDMbMH9al7oDN/+0gIk6nRM+TsLm+N0+NOc/Y2n jJodeC8U+YgptlthSXUHnE5crmls54Xvpbhtl+Md6bx5M5lcV+ATvIe+82X80KPJ nhJoqg0H84vBILz63urwyiN1eNDWFq98XQ6KM7AZmIX4IaaXbgOAaxz8OHv9k+cZ uOYZUdYeq5dBfER4OiAM3TeU1Hu9qthNJ9PpWQ6TCJM/1QDulpZ7DRARUXKR6hLO MzlDyBBvr7UCVf0BpVZ2GrqMwkKUURWJxP6PW89c7asiY1If6yvaLFzjq8avO75/ 4mZZjB4ZUKitsMdtZpLYjwqlIGqLUWcG6xnwWRHiemWu6mHuAsBNE+fliMTx11Uj obsGNarsf0mS8H/u4GMDeiiwTG2b4upQB9hV8BiBRbqm8QuJr7oLQVzSnfdm7HDW G591OJtNV4xS5B2uJzw4mcQFzghTQN/vhbaTuStkJMn6SMcX0dQ5RXCp8NFdlH38 MYoDpyQzd21BS44P/qto =DdoR -----END PGP SIGNATURE----- From juha.hakala@helsinki.fi Tue Jul 16 21:57:15 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20F921F9BF7 for ; Tue, 16 Jul 2013 21:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.104 X-Spam-Level: X-Spam-Status: No, score=-6.104 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxzVx+cUSNsP for ; Tue, 16 Jul 2013 21:57:11 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id C8A6C21F9A2E for ; Tue, 16 Jul 2013 21:57:09 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id r6H4v6qY020403 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 17 Jul 2013 07:57:06 +0300 Message-ID: <51E62422.8010605@helsinki.fi> Date: Wed, 17 Jul 2013 07:57:06 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Peter Saint-Andre References: <51E04659.7060901@stpeter.im> <51E3EBDE.6040906@helsinki.fi> <51E46473.4060700@stpeter.im> <51E4E39F.2090303@helsinki.fi> <6.2.5.6.2.20130716100602.0b561948@resistor.net> <51E5916B.5020101@stpeter.im> <51E5921A.4070303@stpeter.im> <6.2.5.6.2.20130716131044.0b6abfd8@resistor.net> <51E5B667.1040005@stpeter.im> In-Reply-To: <51E5B667.1040005@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] updated URNBIS I-Ds X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 04:57:15 -0000 Hello Peter & SM, It is fine with me if we do not include functional equivalence in rfc2141 at all. Then we can streamline the lexical equivalence chapter by dropping "lexical" and referring to RFC 3986 whenever possible. There are other, more appropriate places to deal with functional equivalence. IETF or other bodies may consider publishing guidelines for URN assignment & resolution. These documents can make the point that a single resource may receive multiple URNs and describe means for determining if this is the case (that is, if URNs are functionally equivalent). Or, perhaps we can say in rfc3406bis that the URN namespaces are not and do not need to be mutually exclusive. Juha On 17.7.2013 0:08, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/16/13 2:52 PM, SM wrote: >> Hi Peter, At 11:34 16-07-2013, Peter Saint-Andre wrote: >>>> That may be. My point is that if application developers wish to >>>> go searching for functional equivalence, they are free to do >>>> so. However, we don't need to say anything about that in >>>> 2141bis, just as RFC 3986 didn't try to define the possible >>>> ways to determine functional equivalence for URIs in general. >>>> What would be the purpose of this >>> text? >>>> What would break if we don't include it? Remember, 2141bis is >>>> about URN syntax, and it seems to me that syntactically all we >>>> can talk about is lexical equivalence. >>> Indeed, I would go farther and assert that we don't need the >>> current text on functional equivalence (Section 7) -- what's said >>> in RFC 3986 is enough and we cite that normatively. >> I'll apologize beforehand for the IETF perspective of my comment. >> >> RFC 3986 is already cited normatively. The draft can avoid getting >> into that. The developer still has the ability to go and search >> for equivalence if he or she wishes. I think that the angle to >> look into is what would break if we don't include the text. If I >> read Juha's message correctly it does not break anything. > I'd agree. > > My philosophy of spec-writing has always been, if it's not mentioned > in the spec then you are free to do something interesting and creative > to solve whatever problems you need to solve in the real world. > Searching for functional equivalence seems to be one of those cases. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJR5bZmAAoJEOoGpJErxa2pK5UP/1u1dLJuHmp/AzDWWGqd803a > G9qX6MPBDfDss6LSpfuJzttszhg0pByvH0X2vaYUeasVZ8pYt7TVO8x9l4xT3qDn > 9kO0K1dVmGXP0bTY/SBCrEtycLTR7Zz7MVZP7y/FDIK2TGoMjZvd0dd11SKT62rL > m2PsJh/14LcwUBkgnAt8H9ozIPDMbMH9al7oDN/+0gIk6nRM+TsLm+N0+NOc/Y2n > jJodeC8U+YgptlthSXUHnE5crmls54Xvpbhtl+Md6bx5M5lcV+ATvIe+82X80KPJ > nhJoqg0H84vBILz63urwyiN1eNDWFq98XQ6KM7AZmIX4IaaXbgOAaxz8OHv9k+cZ > uOYZUdYeq5dBfER4OiAM3TeU1Hu9qthNJ9PpWQ6TCJM/1QDulpZ7DRARUXKR6hLO > MzlDyBBvr7UCVf0BpVZ2GrqMwkKUURWJxP6PW89c7asiY1If6yvaLFzjq8avO75/ > 4mZZjB4ZUKitsMdtZpLYjwqlIGqLUWcG6xnwWRHiemWu6mHuAsBNE+fliMTx11Uj > obsGNarsf0mS8H/u4GMDeiiwTG2b4upQB9hV8BiBRbqm8QuJr7oLQVzSnfdm7HDW > G591OJtNV4xS5B2uJzw4mcQFzghTQN/vhbaTuStkJMn6SMcX0dQ5RXCp8NFdlH38 > MYoDpyQzd21BS44P/qto > =DdoR > -----END PGP SIGNATURE----- -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293 From stpeter@stpeter.im Wed Jul 17 21:22:18 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9198B21F9C86 for ; Wed, 17 Jul 2013 21:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9JdWDvhXWxy for ; Wed, 17 Jul 2013 21:22:09 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D986221F9C33 for ; Wed, 17 Jul 2013 21:22:08 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DC4834138E; Wed, 17 Jul 2013 22:23:29 -0600 (MDT) Message-ID: <51E76D65.8070408@stpeter.im> Date: Wed, 17 Jul 2013 22:21:57 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Juha Hakala References: <51E04659.7060901@stpeter.im> <51E3EBDE.6040906@helsinki.fi> <51E46473.4060700@stpeter.im> <51E4E39F.2090303@helsinki.fi> <6.2.5.6.2.20130716100602.0b561948@resistor.net> <51E5916B.5020101@stpeter.im> <51E5921A.4070303@stpeter.im> <6.2.5.6.2.20130716131044.0b6abfd8@resistor.net> <51E5B667.1040005@stpeter.im> <51E62422.8010605@helsinki.fi> In-Reply-To: <51E62422.8010605@helsinki.fi> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] updated URNBIS I-Ds X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 04:22:19 -0000 On 7/16/13 10:57 PM, Juha Hakala wrote: > Hello Peter & SM, > > It is fine with me if we do not include functional equivalence in > rfc2141 at all. Then we can streamline the lexical equivalence chapter > by dropping "lexical" and referring to RFC 3986 whenever possible. That sounds like an ideal approach. Thanks for your flexibility. > There are other, more appropriate places to deal with functional > equivalence. IETF or other bodies may consider publishing guidelines for > URN assignment & resolution. These documents can make the point that a > single resource may receive multiple URNs and describe means for > determining if this is the case (that is, if URNs are functionally > equivalent). Or, perhaps we can say in rfc3406bis that the URN > namespaces are not and do not need to be mutually exclusive. I shall look at 3406bis more closely to see if there is a good place to mention that topic. Peter From andy@hxr.us Fri Jul 19 10:17:45 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A09821E8101 for ; Fri, 19 Jul 2013 10:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2Ko63cRsVlZ for ; Fri, 19 Jul 2013 10:17:39 -0700 (PDT) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id 6B11021E8100 for ; Fri, 19 Jul 2013 10:17:39 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so4508625pdj.0 for ; Fri, 19 Jul 2013 10:17:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=NDEpyUdXv67CZ7alcgyRfuLwh2kiTGE1x50uugQJQfo=; b=lmTkzH7EzhKaa1ZdxoOkokOS7WYTgZ7hEWzppRY3UefDLdbINyaRjV0nTfIDvk0Lb3 WI7k1SFUsI9GYh8xXtZqEqf1Sydb/RG0QmlyQBYoU2PGVQDFyTk0R7OaVzZjLiD3MvfN wMTwcTr0c8XNWF2i/onPdsj4KXLVeV4N2NHRshjURKvlfqkqonr/OV76otl3Rny/LSGl 5Qsr9nnhaaB5XoYBLRayK4av7HsRLNj3FNS4o8juOkz9R8b7o7EePRZf5GAbHVqvf+3A XSwpl/QuZNTXY4RUA7K412CkWCRqHxMCM3kszoQ6swPyV1MupIKk83bFErcvBeLQGZsT JoeQ== MIME-Version: 1.0 X-Received: by 10.67.2.41 with SMTP id bl9mr19185846pad.109.1374254259067; Fri, 19 Jul 2013 10:17:39 -0700 (PDT) Received: by 10.68.203.69 with HTTP; Fri, 19 Jul 2013 10:17:38 -0700 (PDT) X-Originating-IP: [192.149.252.11] Date: Fri, 19 Jul 2013 13:17:38 -0400 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkFCw014tFTslj8jlQ7CoopJR5CxeJFhdf+2eOAMvwNwUC2hvcHT/jSdlwjD61hg6yo0Yqc Subject: [urn] IETF 87 Agenda X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:17:45 -0000 First, I want to thank everyone for the recent discussions. It looks like this working group is now making significant progress. Second, here is the preliminary agenda for IETF 87 in Berlin. We only have an hour, but a lot of what we need to discuss is finalization of the topics already covered on this list. Again, thanks everybody! URNBis Working Group IETF 87, Berline, DE 08-02-2013 1120-1220 CEST Agenda ------ 1. Note Well and Agenda Bash 2. Discussion of draft-ietf-urnbis-rfc3406bis-urn-ns-reg-06 a. Ready for WGLC? 3. Discussion of draft-ietf-urnbis-rfc2141bis-urn-05 a. Fragments b. Queries c. Equivalence 4. Any Other Business Comments welcome! -andy From andy@hxr.us Fri Jul 19 10:28:26 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C651211E817B for ; Fri, 19 Jul 2013 10:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENayFFYcQno7 for ; Fri, 19 Jul 2013 10:28:21 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0E05F11E818E for ; Fri, 19 Jul 2013 10:28:19 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj3so4697549pad.0 for ; Fri, 19 Jul 2013 10:28:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=jMT2HijOW75rFaoIe7U2d0g6CvEaUMS0QqfSCSPA6UU=; b=GuI5T7Yz924xQRIjSxv9gti+VTDnl6LxEVaasJSGRK6of+8MflzNBciIlfWxKdtewB DtpHAATdESMmVmLpfdywm9svW16Ua6ZI2KMYMx6PijKT1H0bsfnmBBH5TiGY3JXrT6ny n8sVK/VNlA4Czy3elK51O+MZwzJOB+pD1gcwi0cGN9eJwZN+lkHpiaPKwGk6SRtvtDP8 vOGvs690Or2T7gGA36sJv1Nstysj2VfGPS0eEoq8c02L/KBArKyFDcSqUQRB3hc5Vgpq Gk0ewupH/1yf5WoSMakCmKpzdnsS1WtCiL2A9eOhb21M5g/o598Fccns6PU+yJ81aZNE Kzfw== MIME-Version: 1.0 X-Received: by 10.66.139.167 with SMTP id qz7mr19107415pab.157.1374254893379; Fri, 19 Jul 2013 10:28:13 -0700 (PDT) Received: by 10.68.203.69 with HTTP; Fri, 19 Jul 2013 10:28:13 -0700 (PDT) X-Originating-IP: [192.149.252.11] Date: Fri, 19 Jul 2013 13:28:13 -0400 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnnk/zfNsuFGiBYJkGg6VrpCQaExSK4GqjQfZWDstJ9bEO4ArgYbyT7FMYa7eTDrhJ71O2b Subject: [urn] draft-ietf-urnbis-rfc3406bis-urn-ns-reg-06 and formal registration procedures X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:28:26 -0000 Section 6.1 states that formal URN namespace registration is to have IETF Review by publication as an RFC sponsored by an AD. Do we want to keep this process as is or perhaps have one that is less onerous? Both the informal and formal registration processes require the applicant to address comments, so would publication as an independent-stream RFC be sufficient? -andy From stpeter@stpeter.im Fri Jul 19 10:32:35 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175D421E8050 for ; Fri, 19 Jul 2013 10:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvM5eAfeKnYC for ; Fri, 19 Jul 2013 10:32:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 02ED311E80FD for ; Fri, 19 Jul 2013 10:32:25 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E78904149B; Fri, 19 Jul 2013 11:33:54 -0600 (MDT) Message-ID: <51E97821.4020804@stpeter.im> Date: Fri, 19 Jul 2013 11:32:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andrew Newton References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] IETF 87 Agenda X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:32:39 -0000 Hi Andy, thanks for posting this. On 7/19/13 11:17 AM, Andrew Newton wrote: > First, I want to thank everyone for the recent discussions. It looks > like this working group is now making significant progress. Indeed! > Second, here is the preliminary agenda for IETF 87 in Berlin. We only > have an hour, but a lot of what we need to discuss is finalization of > the topics already covered on this list. Again, thanks everybody! > > URNBis Working Group > IETF 87, Berline, DE > 08-02-2013 1120-1220 CEST > > Agenda > ------ > 1. Note Well and Agenda Bash > 2. Discussion of draft-ietf-urnbis-rfc3406bis-urn-ns-reg-06 > a. Ready for WGLC? I promised that I would investigate one issue further and propose some text on the list. I will do that as soon as possible. We might even be able to close that issue before the WG session. > 3. Discussion of draft-ietf-urnbis-rfc2141bis-urn-05 > a. Fragments > b. Queries > c. Equivalence We've talked about removing Section 7. I haven't seen any objections to that, but here again I will propose some text. And naturally if people discover any additional issues, please raise them on the list so that we can make sure we spend session time on topics that require active discussion. > 4. Any Other Business I'll give some thought to more future-oriented topics. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Jul 23 16:16:18 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC2211E817E for ; Tue, 23 Jul 2013 16:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPBipDPFGfra for ; Tue, 23 Jul 2013 16:16:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 22EB611E817B for ; Tue, 23 Jul 2013 16:16:12 -0700 (PDT) Received: from sjc-vpn6-1242.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B0F92414B4; Tue, 23 Jul 2013 17:17:57 -0600 (MDT) Message-ID: <51EF0EB5.5050804@stpeter.im> Date: Tue, 23 Jul 2013 17:16:05 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Juha Hakala References: <51E04659.7060901@stpeter.im> <51E3EBDE.6040906@helsinki.fi> <51E46473.4060700@stpeter.im> <51E4E39F.2090303@helsinki.fi> <6.2.5.6.2.20130716100602.0b561948@resistor.net> <51E5916B.5020101@stpeter.im> <51E5921A.4070303@stpeter.im> <6.2.5.6.2.20130716131044.0b6abfd8@resistor.net> <51E5B667.1040005@stpeter.im> <51E62422.8010605@helsinki.fi> <51E76D65.8070408@stpeter.im> In-Reply-To: <51E76D65.8070408@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] updated URNBIS I-Ds X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 23:16:18 -0000 On 7/17/13 10:21 PM, Peter Saint-Andre wrote: > On 7/16/13 10:57 PM, Juha Hakala wrote: >> Hello Peter & SM, >> >> It is fine with me if we do not include functional equivalence in >> rfc2141 at all. Then we can streamline the lexical equivalence chapter >> by dropping "lexical" and referring to RFC 3986 whenever possible. > > That sounds like an ideal approach. Thanks for your flexibility. > >> There are other, more appropriate places to deal with functional >> equivalence. IETF or other bodies may consider publishing guidelines for >> URN assignment & resolution. These documents can make the point that a >> single resource may receive multiple URNs and describe means for >> determining if this is the case (that is, if URNs are functionally >> equivalent). Or, perhaps we can say in rfc3406bis that the URN >> namespaces are not and do not need to be mutually exclusive. > > I shall look at 3406bis more closely to see if there is a good place to > mention that topic. Section 5.1.2 of 3406bis currently says: It is expected that more than one namespace might serve the same "functional" purpose; the intent of the "Namespace Considerations" section is to provide a record of the proposer's "due diligence" in exploring existing possibilities, for the consideration by the Internet community, expert reviewers, and the IESG. We could expand the first clause a bit. Here is proposed text: URN namespaces are not mutually exclusive, and it is expected that in certain circumstances URNs from different namespaces might serve the same "functional" goal or identify the same resource (e.g., URNs from different namespaces might be assigned to the same resource for purposes that differ in scope or intent). The objective of the "Namespace Considerations" section is to provide a record of the proposer's "due diligence" in exploring existing possibilities, for the consideration by the Internet community, expert reviewers, and the IESG. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Jul 23 16:35:53 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742D411E8173 for ; Tue, 23 Jul 2013 16:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3joE8sCa3Mx3 for ; Tue, 23 Jul 2013 16:35:48 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4130411E8170 for ; Tue, 23 Jul 2013 16:35:48 -0700 (PDT) Received: from sjc-vpn6-1242.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A9B2B414B4; Tue, 23 Jul 2013 17:37:36 -0600 (MDT) Message-ID: <51EF1350.6080406@stpeter.im> Date: Tue, 23 Jul 2013 17:35:44 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "urn@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [urn] text about equivalence in 2141bis and 3406bis X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 23:35:53 -0000 I propose the following changes in 2141bis and 3406bis. 1. Remove Section 7... OLD 7. Functional Equivalence in URNs Functional equivalence is determined within a given namespace and managed by resolvers for that namespace, and thus is beyond the scope of this document. For related considerations with regard to NID registration, see [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]. NEW [nothing] 2. Change "lexical equivalence" to "equivalence"... OLD 6. Lexical Equivalence in URNs 6.1. Procedure For various purposes such as caching, often it is desirable to determine if two URNs are "the same". This is done by testing for "lexical equivalence". Two URNs are lexically equivalent if they are octet-by-octet equal after applying case normalization (as specified in Section 6.2.2.1 of [RFC3986]) to the following constructs: 1. the URI scheme "urn" 2. the NID 3. any percent-encoded characters (see Section 2.1 of [RFC3986]) Percent-encoded characters MUST NOT be decoded, i.e., percent- encoding normalization (as specified in Section 6.2.2.2 of [RFC3986]) MUST NOT be applied. If a query component, fragment identifier component, or both have been appended to the assigned URI, they MUST be ignored for purposes of determining lexical equivalence. URN namespaces MAY define additional rules for lexical equivalence, such as case-insensitivity of the NSS (or parts thereof). Such rules MUST always have the effect of eliminating some of the false negatives obtained by the procedure above and MUST NOT result in treating two URNs as not equivalent if the procedure here says they are equivalent. For related considerations with regard to NID registration, see [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]. 6.2. Examples The following URN comparisons (which use the "example" NID defined in [RFC6963]) highlight the lexical equivalence rules: 1. URN:example:a123,456 2. urn:example:a123,456 3. urn:EXAMPLE:a123,456 4. urn:example:A123,456 5. urn:example:a123%2C456 6. URN:EXAMPLE:a123%2c456 URNs 1, 2, and 3 are lexically equivalent. URN 4 is not lexically equivalent to any of the other URNs in the above set. URNs 5 and 6 are lexically equivalent only to each other. NEW 6. Equivalence of URNs 6.1. Procedure For various purposes such as caching, often it is desirable to determine if two URNs are "the same". This is done by testing for "equivalence" (see Section 6.1 of [RFC3986]). Two URNs are equivalent if they are octet-by-octet equal after applying case normalization (as specified in Section 6.2.2.1 of [RFC3986]) to the following constructs: 1. the URI scheme "urn" 2. the NID 3. any percent-encoded characters (see Section 2.1 of [RFC3986]) Percent-encoded characters MUST NOT be decoded, i.e., percent- encoding normalization (as specified in Section 6.2.2.2 of [RFC3986]) MUST NOT be applied. If a query component, fragment identifier component, or both have been appended to the assigned URI, they MUST be ignored for purposes of determining lexical equivalence. URN namespaces MAY define additional rules for equivalence, such as case-insensitivity of the NSS (or parts thereof). Such rules MUST always have the effect of eliminating some of the false negatives obtained by the procedure above and MUST NOT result in treating two URNs as not equivalent if the procedure here says they are equivalent. For related considerations with regard to NID registration, see [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]. 6.2. Examples The following URN comparisons (which use the "example" NID defined in [RFC6963]) highlight the equivalence rules: 1. URN:example:a123,456 2. urn:example:a123,456 3. urn:EXAMPLE:a123,456 4. urn:example:A123,456 5. urn:example:a123%2C456 6. URN:EXAMPLE:a123%2c456 URNs 1, 2, and 3 are equivalent. URN 4 is not equivalent to any of the other URNs in the above set. URNs 5 and 6 are equivalent only to each other. 3. We would also need to make associated changes in 3406bis... a. Section 5.1.2 OLD Third, the "Security Considerations" section describes any potential security-related issues with regard to assignment, use, and resolution of identifiers within the namespace. Examples of such issues include the consequences of producing false negatives and false positives during comparison for lexical equivalence (see also [RFC6943]), leakage of private information when identifiers are communicated on the public Internet, the potential for directory harvesting, and the issues discussed in [RFC3552]. NEW Third, the "Security Considerations" section describes any potential security-related issues with regard to assignment, use, and resolution of identifiers within the namespace. Examples of such issues include the consequences of producing false negatives and false positives during comparison for equivalence (see also [RFC6943]), leakage of private information when identifiers are communicated on the public Internet, the potential for directory harvesting, and the issues discussed in [RFC3552]. b. Section 7 OLD Rules for lexical equivalence: NEW Rules for equivalence: Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Jul 23 16:40:40 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106EF11E817B for ; Tue, 23 Jul 2013 16:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iorYuuSKSmnW for ; Tue, 23 Jul 2013 16:40:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B836511E8178 for ; Tue, 23 Jul 2013 16:40:34 -0700 (PDT) Received: from sjc-vpn6-1242.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B37DB414B4; Tue, 23 Jul 2013 17:42:24 -0600 (MDT) Message-ID: <51EF1470.5040706@stpeter.im> Date: Tue, 23 Jul 2013 17:40:32 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andrew Newton References: <51E97821.4020804@stpeter.im> In-Reply-To: <51E97821.4020804@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] IETF 87 Agenda X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 23:40:40 -0000 On 7/19/13 11:32 AM, Peter Saint-Andre wrote: > Hi Andy, thanks for posting this. > > On 7/19/13 11:17 AM, Andrew Newton wrote: >> First, I want to thank everyone for the recent discussions. It looks >> like this working group is now making significant progress. > > Indeed! > >> Second, here is the preliminary agenda for IETF 87 in Berlin. We only >> have an hour, but a lot of what we need to discuss is finalization of >> the topics already covered on this list. Again, thanks everybody! >> >> URNBis Working Group >> IETF 87, Berline, DE >> 08-02-2013 1120-1220 CEST >> >> Agenda >> ------ >> 1. Note Well and Agenda Bash >> 2. Discussion of draft-ietf-urnbis-rfc3406bis-urn-ns-reg-06 >> a. Ready for WGLC? > > I promised that I would investigate one issue further and propose some > text on the list. I will do that as soon as possible. Done. > We might even be > able to close that issue before the WG session. > >> 3. Discussion of draft-ietf-urnbis-rfc2141bis-urn-05 >> a. Fragments >> b. Queries >> c. Equivalence > > We've talked about removing Section 7. I haven't seen any objections to > that, but here again I will propose some text. Done. > And naturally if people discover any additional issues, please raise > them on the list so that we can make sure we spend session time on > topics that require active discussion. I have uploaded draft slides for the meeting: https://stpeter.im/files/ietf87-urnbis-2141bis-3406bis.pdf Feedback is welcome. Peter -- Peter Saint-Andre https://stpeter.im/ From duerst@it.aoyama.ac.jp Tue Jul 23 22:07:52 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97C311E80A5 for ; Tue, 23 Jul 2013 22:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.79 X-Spam-Level: X-Spam-Status: No, score=-103.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrpaOgcMrPx4 for ; Tue, 23 Jul 2013 22:07:39 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id E86DE11E81E1 for ; Tue, 23 Jul 2013 22:07:37 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r6O57HA1003193; Wed, 24 Jul 2013 14:07:18 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 0c6e_dcca_e950b1f4_f41e_11e2_a9e8_001e6722eec2; Wed, 24 Jul 2013 14:07:17 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 54753BF4E3; Wed, 24 Jul 2013 14:05:20 +0900 (JST) Message-ID: <51EF60E9.7040306@it.aoyama.ac.jp> Date: Wed, 24 Jul 2013 14:06:49 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <51E04659.7060901@stpeter.im> <51E3EBDE.6040906@helsinki.fi> <51E46473.4060700@stpeter.im> <51E4E39F.2090303@helsinki.fi> <6.2.5.6.2.20130716100602.0b561948@resistor.net> <51E5916B.5020101@stpeter.im> <51E5921A.4070303@stpeter.im> <6.2.5.6.2.20130716131044.0b6abfd8@resistor.net> <51E5B667.1040005@stpeter.im> <51E62422.8010605@helsinki.fi> <51E76D65.8070408@stpeter.im> <51EF0EB5.5050804@stpeter.im> In-Reply-To: <51EF0EB5.5050804@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] updated URNBIS I-Ds X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 05:07:52 -0000 Looks good to me. Regards, Martin. On 2013/07/24 8:16, Peter Saint-Andre wrote: > On 7/17/13 10:21 PM, Peter Saint-Andre wrote: >> On 7/16/13 10:57 PM, Juha Hakala wrote: >>> Hello Peter& SM, >>> >>> It is fine with me if we do not include functional equivalence in >>> rfc2141 at all. Then we can streamline the lexical equivalence chapter >>> by dropping "lexical" and referring to RFC 3986 whenever possible. >> >> That sounds like an ideal approach. Thanks for your flexibility. >> >>> There are other, more appropriate places to deal with functional >>> equivalence. IETF or other bodies may consider publishing guidelines for >>> URN assignment& resolution. These documents can make the point that a >>> single resource may receive multiple URNs and describe means for >>> determining if this is the case (that is, if URNs are functionally >>> equivalent). Or, perhaps we can say in rfc3406bis that the URN >>> namespaces are not and do not need to be mutually exclusive. >> >> I shall look at 3406bis more closely to see if there is a good place to >> mention that topic. > > Section 5.1.2 of 3406bis currently says: > > It is expected that more than one namespace might serve the same > "functional" purpose; the intent of the "Namespace Considerations" > section is to provide a record of the proposer's "due diligence" in > exploring existing possibilities, for the consideration by the > Internet community, expert reviewers, and the IESG. > > We could expand the first clause a bit. Here is proposed text: > > URN namespaces are not mutually exclusive, and it is expected that > in certain circumstances URNs from different namespaces might serve > the same "functional" goal or identify the same resource (e.g., > URNs from different namespaces might be assigned to the same > resource for purposes that differ in scope or intent). The > objective of the "Namespace Considerations" section is to provide a > record of the proposer's "due diligence" in exploring existing > possibilities, for the consideration by the Internet community, > expert reviewers, and the IESG. > > Peter > From sm@resistor.net Tue Jul 23 22:30:43 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF46011E8383 for ; Tue, 23 Jul 2013 22:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD+vvajX59yj for ; Tue, 23 Jul 2013 22:30:43 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C88B11E81F2 for ; Tue, 23 Jul 2013 22:30:42 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6O5UaYB027728; Tue, 23 Jul 2013 22:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1374643841; bh=+7wDiKjVfF8gtJFQZF8ETcUd224m/RcF/8bFQmp0ud8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=snMC5CRjLLCqaLnk8GTMXWKtvb7eDv9Ond3i2HMm3HWMWCNUwT0wRmwOct7igHFT1 BJpk1WFaMErkgG3gvL86h+zNiRN+WMsZva/jBO3xX3ecwNY9mKWtJ6c2yV3vRCRv4g 4wrHiV72R/enO0jan/ZJTy2iH4jR8lrqFpPM8rHs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1374643841; i=@resistor.net; bh=+7wDiKjVfF8gtJFQZF8ETcUd224m/RcF/8bFQmp0ud8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=i9X1jfOnrAyN7BgkgMbHzgWH7TL5yWAKaXabvI9yrHzdLCLxwSnvUHnxBrPzMb34I CvIa4kbHbZs4IW2qF1I08AQXT1ciIzKztkOEt+YDvZlzt4NTx/xagKo+5+FOk+uPiv s5rpVMkw+qqkvweiq4+cgDrB+6x69EuuRXF11MeA= Message-Id: <6.2.5.6.2.20130723221350.0ccd84d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 23 Jul 2013 22:28:34 -0700 To: Peter Saint-Andre From: SM In-Reply-To: <51EF0EB5.5050804@stpeter.im> References: <51E04659.7060901@stpeter.im> <51E3EBDE.6040906@helsinki.fi> <51E46473.4060700@stpeter.im> <51E4E39F.2090303@helsinki.fi> <6.2.5.6.2.20130716100602.0b561948@resistor.net> <51E5916B.5020101@stpeter.im> <51E5921A.4070303@stpeter.im> <6.2.5.6.2.20130716131044.0b6abfd8@resistor.net> <51E5B667.1040005@stpeter.im> <51E62422.8010605@helsinki.fi> <51E76D65.8070408@stpeter.im> <51EF0EB5.5050804@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: urn@ietf.org Subject: Re: [urn] updated URNBIS I-Ds X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 05:30:43 -0000 Hi Peter, At 16:16 23-07-2013, Peter Saint-Andre wrote: >Section 5.1.2 of 3406bis currently says: > > It is expected that more than one namespace might serve the same > "functional" purpose; the intent of the "Namespace Considerations" > section is to provide a record of the proposer's "due diligence" in > exploring existing possibilities, for the consideration by the > Internet community, expert reviewers, and the IESG. > >We could expand the first clause a bit. Here is proposed text: > > URN namespaces are not mutually exclusive, and it is expected that > in certain circumstances URNs from different namespaces might serve > the same "functional" goal or identify the same resource (e.g., > URNs from different namespaces might be assigned to the same > resource for purposes that differ in scope or intent). The > objective of the "Namespace Considerations" section is to provide a > record of the proposer's "due diligence" in exploring existing > possibilities, for the consideration by the Internet community, > expert reviewers, and the IESG. The proposed text looks ok. Regards, -sm From stpeter@stpeter.im Wed Jul 31 04:43:08 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3918421F9CC2 for ; Wed, 31 Jul 2013 04:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EN0G3KWDmeuk for ; Wed, 31 Jul 2013 04:43:02 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 91A2121F9D90 for ; Wed, 31 Jul 2013 04:43:02 -0700 (PDT) Received: from che-vpn-cluster-2-489.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5C07E40046; Wed, 31 Jul 2013 05:45:16 -0600 (MDT) Message-ID: <51F8F843.6030307@stpeter.im> Date: Wed, 31 Jul 2013 13:42:59 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: urn@ietf.org References: <51E97821.4020804@stpeter.im> <51EF1470.5040706@stpeter.im> In-Reply-To: <51EF1470.5040706@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [urn] IETF 87 Agenda X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 11:43:08 -0000 On 7/24/13 1:40 AM, Peter Saint-Andre wrote: > I have uploaded draft slides for the meeting: > > https://stpeter.im/files/ietf87-urnbis-2141bis-3406bis.pdf Based on further reflection and a hallway conversation here in Berlin, I have updated those slides. Chairs, please retrieve and upload the slides again. Peter -- Peter Saint-Andre https://stpeter.im/ From marc.blanchet@viagenie.ca Wed Jul 31 04:55:09 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECC921E8132 for ; Wed, 31 Jul 2013 04:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULAmcdWYgnam for ; Wed, 31 Jul 2013 04:55:09 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id BBE4E21E80D3 for ; Wed, 31 Jul 2013 04:55:08 -0700 (PDT) Received: from h195.viagenie.ca (h195.viagenie.ca [206.123.31.195]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 08D9746FC2 for ; Wed, 31 Jul 2013 07:55:07 -0400 (EDT) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_D08732E8-5286-444B-8CB6-EEF8BD81D028" Date: Wed, 31 Jul 2013 13:55:06 +0200 References: <20130731115043.24006.31384.idtracker@ietfa.amsl.com> To: "urn@ietf.org" Message-Id: <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [urn] Fwd: New Version Notification for draft-blanchet-urn-ianachange-00.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 11:55:09 -0000 --Apple-Mail=_D08732E8-5286-444B-8CB6-EEF8BD81D028 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 - without paying attention to urn ML lately, I wrote a few months ago a = draft that I circulated to a few people (before publishing) about making = registration of urn formal namespace much less burden on IESG by having = Expert review. I also wanted to make the template much less verbose = since it requests stuff that may no more be 2013ish..., but did not take = this into my draft. =20 - I had a chat with Peter St-Andr=E9 that he was working on this for the = 3406bis.=20 So here is my small contribution to the discussion. Marc. D=E9but du message r=E9exp=E9di=E9 : > De : internet-drafts@ietf.org > Objet : New Version Notification for = draft-blanchet-urn-ianachange-00.txt > Date : 31 juillet 2013 13:50:43 UTC+02:00 > =C0 : Marc Blanchet >=20 >=20 > A new version of I-D, draft-blanchet-urn-ianachange-00.txt > has been successfully submitted by Marc Blanchet and posted to the > IETF repository. >=20 > Filename: draft-blanchet-urn-ianachange > Revision: 00 > Title: Uniform Resource Names (URN) Formal Namespace = IANA Registration > Creation date: 2013-07-31 > Group: Individual Submission > Number of pages: 3 > URL: = http://www.ietf.org/internet-drafts/draft-blanchet-urn-ianachange-00.txt > Status: = http://datatracker.ietf.org/doc/draft-blanchet-urn-ianachange > Htmlized: = http://tools.ietf.org/html/draft-blanchet-urn-ianachange-00 >=20 >=20 > Abstract: > Per RFC3406, Uniform Resource Names formal namespace identifier = (NID) > registration requires the publication of an RFC from the requestor. > Experience shows that this requirement is too high. This document > updates the IANA registration policy for formal NID to Expert = review. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat --Apple-Mail=_D08732E8-5286-444B-8CB6-EEF8BD81D028 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 - = without paying attention to urn ML lately, I wrote a few months ago a = draft that I circulated to a few people (before publishing) about making = registration of urn formal namespace much less burden on IESG by having = Expert review. I also wanted to make the template much less verbose = since it requests stuff that may no more be 2013ish..., but did not take = this into my draft.  
- I had a chat with Peter St-Andr=E9 that = he was working on this for the = 3406bis. 

So here is my small contribution = to the = discussion.

Marc.

D=E9= but du message r=E9exp=E9di=E9 :

Objet : New Version Notification for = draft-blanchet-urn-ianachange-00.txt
Date : 31 juillet 2013 = 13:50:43 UTC+02:00
=C0 : Marc Blanchet <marc.blanchet@viagenie.ca>= ;


A new version of I-D, = draft-blanchet-urn-ianachange-00.txt
has been successfully submitted = by Marc Blanchet and posted to the
IETF = repository.

Filename: = draft-blanchet-urn-ianachange
Revision: 00
Title: Uniform = Resource Names (URN) Formal Namespace IANA Registration
Creation = date: = 2013-07-31
Group: Individual Submission
Number = of pages: 3
URL: =             http://www.ietf.org/internet-drafts/draft-blanchet-urn-ianachange-= 00.txt
Status: =          htt= p://datatracker.ietf.org/doc/draft-blanchet-urn-ianachange
Htmlized= :        http:= //tools.ietf.org/html/draft-blanchet-urn-ianachange-00


Abst= ract:
  Per RFC3406, Uniform Resource Names formal = namespace identifier (NID)
  registration requires the = publication of an RFC from the requestor.
  Experience = shows that this requirement is too high.  This document
=   updates the IANA registration policy for formal NID to = Expert review.




Please note that it may take a couple = of minutes from the time of submission
until the htmlized version and = diff are available at tools.ietf.org.

The IETF = Secretariat

= --Apple-Mail=_D08732E8-5286-444B-8CB6-EEF8BD81D028-- From stpeter@stpeter.im Wed Jul 31 05:28:34 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D069511E817B for ; Wed, 31 Jul 2013 05:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.426 X-Spam-Level: X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJ1+1ooC0koL for ; Wed, 31 Jul 2013 05:28:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE7E11E8177 for ; Wed, 31 Jul 2013 05:28:12 -0700 (PDT) Received: from che-vpn-cluster-2-489.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B64A640046; Wed, 31 Jul 2013 06:30:24 -0600 (MDT) Message-ID: <51F902D7.5070901@stpeter.im> Date: Wed, 31 Jul 2013 14:28:07 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Marc Blanchet References: <20130731115043.24006.31384.idtracker@ietfa.amsl.com> <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> In-Reply-To: <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "urn@ietf.org" Subject: Re: [urn] Fwd: New Version Notification for draft-blanchet-urn-ianachange-00.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:28:35 -0000 On 7/31/13 1:55 PM, Marc Blanchet wrote: > - without paying attention to urn ML lately, I wrote a few months ago a > draft that I circulated to a few people (before publishing) about making > registration of urn formal namespace much less burden on IESG by having > Expert review. I also wanted to make the template much less verbose > since it requests stuff that may no more be 2013ish..., but did not take > this into my draft. > - I had a chat with Peter St-André that he was working on this for the > 3406bis. > > So here is my small contribution to the discussion. Thanks, Marc! You raise two issues. I shall reply separately regarding each issue, and change the subject of your message. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Jul 31 05:39:48 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D828921F873C for ; Wed, 31 Jul 2013 05:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRorVe9-lxyB for ; Wed, 31 Jul 2013 05:39:44 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9E97A21F8C4B for ; Wed, 31 Jul 2013 05:38:49 -0700 (PDT) Received: from che-vpn-cluster-2-489.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C11EC40046; Wed, 31 Jul 2013 06:41:03 -0600 (MDT) Message-ID: <51F90556.5020205@stpeter.im> Date: Wed, 31 Jul 2013 14:38:46 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Marc Blanchet References: <20130731115043.24006.31384.idtracker@ietfa.amsl.com> <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> In-Reply-To: <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: [urn] NID registration policy (was: Re: Fwd: New Version Notification for draft-blanchet-urn-ianachange-00.txt) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:39:49 -0000 On 7/31/13 1:55 PM, Marc Blanchet wrote: > making > registration of urn formal namespace much less burden on IESG by having > Expert review. We will discuss this on Friday, but here are some considerations: The current RFC 5226 policy ("IETF Consensus") requires publication of an RFC that is approved for publication by the IESG. This means that an Area Director needs to sponsor it, it needs to undergo IETF Last Call, etc. A less restrictive policy would be "RFC Required". This means that someone could, for instance, publish an RFC through the Independent Submissions stream, see https://www.rfc-editor.org/indsubs.html An even less restrictive policy would be "Specfication Required", which means that someone could publish a document via some other standards development organization (or even a stable website - the rules are a bit fuzzy). A yet more loose policy would be "Expert Review", which in practice means that someone would simply need to send a completed template to the urn-nid@ietf.org list. In any case, I think we need to provide guidelines to reviewers (since in all cases review happens on the urn-nid list). Here is a document that provides similar guidelines for another IANA registry: https://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors/ Peter -- Peter Saint-Andre https://stpeter.im/ From marc.blanchet@viagenie.ca Wed Jul 31 05:43:13 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078CF21F9F4F for ; Wed, 31 Jul 2013 05:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrMhQW-DaKcu for ; Wed, 31 Jul 2013 05:43:11 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 47B7321F9EED for ; Wed, 31 Jul 2013 05:43:11 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1001] (unknown [IPv6:2620:0:230:2001::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 780B0403CF; Wed, 31 Jul 2013 08:43:10 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: <51F90556.5020205@stpeter.im> Date: Wed, 31 Jul 2013 14:43:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3DCA5279-6E44-48EE-BB64-6F3C3C91AB8C@viagenie.ca> References: <20130731115043.24006.31384.idtracker@ietfa.amsl.com> <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> <51F90556.5020205@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: "urn@ietf.org" Subject: Re: [urn] NID registration policy (was: Re: Fwd: New Version Notification for draft-blanchet-urn-ianachange-00.txt) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:43:13 -0000 Le 2013-07-31 =E0 14:38, Peter Saint-Andre a =E9crit = : > On 7/31/13 1:55 PM, Marc Blanchet wrote: >=20 >> making >> registration of urn formal namespace much less burden on IESG by = having >> Expert review. =20 >=20 > We will discuss this on Friday, but here are some considerations: >=20 > The current RFC 5226 policy ("IETF Consensus") requires publication of > an RFC that is approved for publication by the IESG. This means that = an > Area Director needs to sponsor it, it needs to undergo IETF Last Call, = etc. >=20 > A less restrictive policy would be "RFC Required". This means that > someone could, for instance, publish an RFC through the Independent > Submissions stream, see https://www.rfc-editor.org/indsubs.html >=20 > An even less restrictive policy would be "Specfication Required", = which > means that someone could publish a document via some other standards > development organization (or even a stable website - the rules are a = bit > fuzzy). >=20 > A yet more loose policy would be "Expert Review", which in practice > means that someone would simply need to send a completed template to = the > urn-nid@ietf.org list. In some ways, "Specification Required" may be more loose than Expert = Review, because if the requestor "just" point to a "dumb" specification, = then he may get the assignment. i.e. the existence of the specification = does not mean you know what you are doing... (well, we can spin off a = discussion on that statement, but that is not the point). So I'm in favor of "expert review", lightweight, that would have = knowledge to verify that the requestor know what he is doing. The = template (the other topic) shall contain a request to URL to a document = from the requestor about the usage they intend to do with the URN. So = this way, there is also an "hidden Specification Required". Marc. >=20 > In any case, I think we need to provide guidelines to reviewers (since > in all cases review happens on the urn-nid list). Here is a document > that provides similar guidelines for another IANA registry: >=20 > https://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors/ >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ From stpeter@stpeter.im Wed Jul 31 05:43:18 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F72521F9F20 for ; Wed, 31 Jul 2013 05:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ju03oDwGj8BG for ; Wed, 31 Jul 2013 05:43:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8998B21F9F31 for ; Wed, 31 Jul 2013 05:43:12 -0700 (PDT) Received: from che-vpn-cluster-2-489.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9C97D40046; Wed, 31 Jul 2013 06:45:26 -0600 (MDT) Message-ID: <51F9065D.3000301@stpeter.im> Date: Wed, 31 Jul 2013 14:43:09 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Marc Blanchet References: <20130731115043.24006.31384.idtracker@ietfa.amsl.com> <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> In-Reply-To: <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: [urn] registration template (was: Re: Fwd: New Version Notification for draft-blanchet-urn-ianachange-00.txt) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:43:18 -0000 On 7/31/13 1:55 PM, Marc Blanchet wrote: > I also wanted to make the template much less verbose > since it requests stuff that may no more be 2013ish... I am in favor of making the template less verbose. I had tried to minimize the diff between 3406 and 3406bis. If the WG would like to make further simplifications, I would be happy to discuss that. However, I have not yet given it much thought. Suggestions are welcome. (Oh, and I also think that the template ought to include the "Namespace Considerations", "Community Considerations", and "Security Considerations" since that would enable us to just use the template and not require a specification, if we decide to go with Expert Review as the RFC 5226 registration policy.) Peter -- Peter Saint-Andre https://stpeter.im/ From marc.blanchet@viagenie.ca Wed Jul 31 05:46:52 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1FE21F9DA0 for ; Wed, 31 Jul 2013 05:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bM96iPlBtuLQ for ; Wed, 31 Jul 2013 05:46:51 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F26C21F9EE9 for ; Wed, 31 Jul 2013 05:46:41 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1001] (unknown [IPv6:2620:0:230:2001::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8B4B0403CF; Wed, 31 Jul 2013 08:46:40 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: <51F9065D.3000301@stpeter.im> Date: Wed, 31 Jul 2013 14:46:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <46892C63-C522-4214-80F6-6F00F7B9012F@viagenie.ca> References: <20130731115043.24006.31384.idtracker@ietfa.amsl.com> <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> <51F9065D.3000301@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: "urn@ietf.org" Subject: Re: [urn] registration template (was: Re: Fwd: New Version Notification for draft-blanchet-urn-ianachange-00.txt) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:46:52 -0000 Le 2013-07-31 =E0 14:43, Peter Saint-Andre a =E9crit = : > On 7/31/13 1:55 PM, Marc Blanchet wrote: >=20 >> I also wanted to make the template much less verbose >> since it requests stuff that may no more be 2013ish... >=20 > I am in favor of making the template less verbose. I was using "verbose", but I guess it is not the right word. It is about = only asking the relevant questions given the state of things today. And = the relevant questions that are "just" enough for the expert to = review/agree/disagree with the request. (I know I'm binding the two = topics now...).=20 > I had tried to > minimize the diff between 3406 and 3406bis. If the WG would like to = make > further simplifications, I would be happy to discuss that. However, I > have not yet given it much thought. Suggestions are welcome. yeah, I'm not sure I'll have time before urn friday morning to give a = good suggestion to chew on. But will do later. Marc. >=20 > (Oh, and I also think that the template ought to include the = "Namespace > Considerations", "Community Considerations", and "Security > Considerations" since that would enable us to just use the template = and > not require a specification, if we decide to go with Expert Review as > the RFC 5226 registration policy.) >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ From stpeter@stpeter.im Wed Jul 31 05:49:30 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F6811E80E4 for ; Wed, 31 Jul 2013 05:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDRC-o7JvAOo for ; Wed, 31 Jul 2013 05:49:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 32DA521F9DA0 for ; Wed, 31 Jul 2013 05:49:25 -0700 (PDT) Received: from che-vpn-cluster-2-489.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7557740046; Wed, 31 Jul 2013 06:51:39 -0600 (MDT) Message-ID: <51F907D2.8030309@stpeter.im> Date: Wed, 31 Jul 2013 14:49:22 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Marc Blanchet References: <20130731115043.24006.31384.idtracker@ietfa.amsl.com> <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> <51F90556.5020205@stpeter.im> <3DCA5279-6E44-48EE-BB64-6F3C3C91AB8C@viagenie.ca> In-Reply-To: <3DCA5279-6E44-48EE-BB64-6F3C3C91AB8C@viagenie.ca> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "urn@ietf.org" Subject: Re: [urn] NID registration policy X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:49:30 -0000 On 7/31/13 2:43 PM, Marc Blanchet wrote: > > Le 2013-07-31 à 14:38, Peter Saint-Andre a écrit > : > >> On 7/31/13 1:55 PM, Marc Blanchet wrote: >> >>> making registration of urn formal namespace much less burden on >>> IESG by having Expert review. >> >> We will discuss this on Friday, but here are some considerations: >> >> The current RFC 5226 policy ("IETF Consensus") requires publication >> of an RFC that is approved for publication by the IESG. This means >> that an Area Director needs to sponsor it, it needs to undergo IETF >> Last Call, etc. >> >> A less restrictive policy would be "RFC Required". This means that >> someone could, for instance, publish an RFC through the >> Independent Submissions stream, see >> https://www.rfc-editor.org/indsubs.html >> >> An even less restrictive policy would be "Specfication Required", >> which means that someone could publish a document via some other >> standards development organization (or even a stable website - the >> rules are a bit fuzzy). >> >> A yet more loose policy would be "Expert Review", which in >> practice means that someone would simply need to send a completed >> template to the urn-nid@ietf.org list. > > In some ways, "Specification Required" may be more loose than Expert > Review, because if the requestor "just" point to a "dumb" > specification, then he may get the assignment. i.e. the existence of > the specification does not mean you know what you are doing... (well, > we can spin off a discussion on that statement, but that is not the > point). > > So I'm in favor of "expert review", lightweight, that would have > knowledge to verify that the requestor know what he is doing. The > template (the other topic) shall contain a request to URL to a > document from the requestor about the usage they intend to do with > the URN. So this way, there is also an "hidden Specification > Required". Without my document editor hat on, I think Expert Review would be just fine (and I do think the expert reviewers would normally want to see some kind of documentation to make sure the folks assigning URNs under the requested namespace seem to know what they are doing). Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Jul 31 05:53:01 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E98E21F99B7 for ; Wed, 31 Jul 2013 05:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQ63Kn5QCgBo for ; Wed, 31 Jul 2013 05:52:48 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 67F1121F99FB for ; Wed, 31 Jul 2013 05:52:47 -0700 (PDT) Received: from che-vpn-cluster-2-489.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9FA3A40046; Wed, 31 Jul 2013 06:55:01 -0600 (MDT) Message-ID: <51F9089C.2060205@stpeter.im> Date: Wed, 31 Jul 2013 14:52:44 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Marc Blanchet References: <20130731115043.24006.31384.idtracker@ietfa.amsl.com> <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> <51F9065D.3000301@stpeter.im> <46892C63-C522-4214-80F6-6F00F7B9012F@viagenie.ca> In-Reply-To: <46892C63-C522-4214-80F6-6F00F7B9012F@viagenie.ca> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "urn@ietf.org" Subject: Re: [urn] registration template X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:53:01 -0000 On 7/31/13 2:46 PM, Marc Blanchet wrote: > Le 2013-07-31 à 14:43, Peter Saint-Andre a écrit > : > >> On 7/31/13 1:55 PM, Marc Blanchet wrote: >> >>> I also wanted to make the template much less verbose since it >>> requests stuff that may no more be 2013ish... >> >> I am in favor of making the template less verbose. > > I was using "verbose", but I guess it is not the right word. It is > about only asking the relevant questions given the state of things > today. And the relevant questions that are "just" enough for the > expert to review/agree/disagree with the request. (I know I'm > binding the two topics now...). Yes, I understand. I don't think the two are bound, because even under the current policy *someone* will be reviewing the template (but now it's the IESG). >> I had tried to minimize the diff between 3406 and 3406bis. If the >> WG would like to make further simplifications, I would be happy to >> discuss that. However, I have not yet given it much thought. >> Suggestions are welcome. > > yeah, I'm not sure I'll have time before urn friday morning to give a > good suggestion to chew on. But will do later. Understood. We don't need suggestions by Friday for sure, but I'll chew on it before then as well. Peter -- Peter Saint-Andre https://stpeter.im/ From barryleiba.mailing.lists@gmail.com Wed Jul 31 06:33:38 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEC021F9EA1 for ; Wed, 31 Jul 2013 06:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.973 X-Spam-Level: X-Spam-Status: No, score=-101.973 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vs1tdLgLGyNZ for ; Wed, 31 Jul 2013 06:33:37 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1E73B21F9E99 for ; Wed, 31 Jul 2013 06:33:37 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id oz10so751427veb.17 for ; Wed, 31 Jul 2013 06:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Q2GiAewws2P8CsMiX4iYXz4R/WXGZPYg8Bkgxq4+MBM=; b=h6Psc6oic6y07tq2O9BEoKR8AWsw1uSW2GuVEjfaMFYIfuhwUXqFm46mmZCvEzjRQy fF+6jGGeZ3VHBV31B0a8iur2YNc97YoDok9F0kUPY9VNo2/9kfvFoeN+fEGU4t1lL/u0 DI4rp0WtGfELRnEb7Qtn3dg1dUN2xBjnzvGuUMH+WaPk0NzAkiEkJj5tr5x12QpYWLTh Cbv2SXXy2dArSQ39hFZW0s9VrlNEyf5ORH/EPnOuOszbS1eYg/S5LYHNDYHRzNTXNcSt OIR8GxF2naN+uVbIeeLZEoTwRmwmhx4VzU8l2M2OfNQevfYKXgR/0ywttSuKXRCO+KYd vWJw== MIME-Version: 1.0 X-Received: by 10.220.98.68 with SMTP id p4mr11500771vcn.28.1375277616490; Wed, 31 Jul 2013 06:33:36 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Wed, 31 Jul 2013 06:33:36 -0700 (PDT) In-Reply-To: <3DCA5279-6E44-48EE-BB64-6F3C3C91AB8C@viagenie.ca> References: <20130731115043.24006.31384.idtracker@ietfa.amsl.com> <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> <51F90556.5020205@stpeter.im> <3DCA5279-6E44-48EE-BB64-6F3C3C91AB8C@viagenie.ca> Date: Wed, 31 Jul 2013 09:33:36 -0400 X-Google-Sender-Auth: g0-s8SSaaRAnR0GH0ZuNPwf9drs Message-ID: From: Barry Leiba To: Marc Blanchet Content-Type: text/plain; charset=ISO-8859-1 Cc: "urn@ietf.org" Subject: Re: [urn] NID registration policy (was: Re: Fwd: New Version Notification for draft-blanchet-urn-ianachange-00.txt) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:33:38 -0000 >> An even less restrictive policy would be "Specfication Required", which >> means that someone could publish a document via some other standards >> development organization (or even a stable website - the rules are a bit >> fuzzy). >> >> A yet more loose policy would be "Expert Review", which in practice >> means that someone would simply need to send a completed template to the >> urn-nid@ietf.org list. > > In some ways, "Specification Required" may be more loose than Expert Review, > because if the requestor "just" point to a "dumb" specification, then he may get > the assignment. i.e. the existence of the specification does not mean you know > what you are doing... (well, we can spin off a discussion on that statement, but > that is not the point). No. Specification Required includes review by a Designated Expert, as in Expert Review. In other words, Specification Required is [Expert Review + a stable, public specification]. > So I'm in favor of "expert review", lightweight, that would have knowledge to > verify that the requestor know what he is doing. The template (the other topic) > shall contain a request to URL to a document from the requestor about the > usage they intend to do with the URN. So this way, there is also an "hidden > Specification Required". If you want to require a specification, then it should be Specification Required. You should include instructions to the Designated Expert about review criteria, and what level of specification to look for. The only time it makes sense to try to do this "hidden Spec Req" thing is when you want First Come First Served, but you want the registration to point to some sort of reference document. Barry From stpeter@stpeter.im Wed Jul 31 06:46:43 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC3E11E8178 for ; Wed, 31 Jul 2013 06:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHM2a45VE1My for ; Wed, 31 Jul 2013 06:46:37 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE4F21F9B11 for ; Wed, 31 Jul 2013 06:46:36 -0700 (PDT) Received: from che-vpn-cluster-2-456.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B21D540046; Wed, 31 Jul 2013 07:48:50 -0600 (MDT) Message-ID: <51F91539.4050801@stpeter.im> Date: Wed, 31 Jul 2013 15:46:33 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Barry Leiba References: <20130731115043.24006.31384.idtracker@ietfa.amsl.com> <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> <51F90556.5020205@stpeter.im> <3DCA5279-6E44-48EE-BB64-6F3C3C91AB8C@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] NID registration policy X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:46:43 -0000 On 7/31/13 3:33 PM, Barry Leiba wrote: >>> An even less restrictive policy would be "Specfication Required", which >>> means that someone could publish a document via some other standards >>> development organization (or even a stable website - the rules are a bit >>> fuzzy). >>> >>> A yet more loose policy would be "Expert Review", which in practice >>> means that someone would simply need to send a completed template to the >>> urn-nid@ietf.org list. >> >> In some ways, "Specification Required" may be more loose than Expert Review, >> because if the requestor "just" point to a "dumb" specification, then he may get >> the assignment. i.e. the existence of the specification does not mean you know >> what you are doing... (well, we can spin off a discussion on that statement, but >> that is not the point). > > No. > > Specification Required includes review by a Designated Expert, as in > Expert Review. In other words, Specification Required is [Expert > Review + a stable, public specification]. > >> So I'm in favor of "expert review", lightweight, that would have knowledge to >> verify that the requestor know what he is doing. The template (the other topic) >> shall contain a request to URL to a document from the requestor about the >> usage they intend to do with the URN. So this way, there is also an "hidden >> Specification Required". > > If you want to require a specification, then it should be > Specification Required. You should include instructions to the > Designated Expert about review criteria, and what level of > specification to look for. Barry, thanks for the clarifications. I agree with your interpretation of RFC 5226. Also, note that Expert Review could require documentation that doesn't necessarily take the form of "a permanent and readily available public specification" as in Specification Required. Thus we're not saying that no documentation would be necessary. Peter -- Peter Saint-Andre https://stpeter.im/ From ted.ietf@gmail.com Wed Jul 31 06:49:54 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B09011E8194 for ; Wed, 31 Jul 2013 06:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teR1o+XhXula for ; Wed, 31 Jul 2013 06:49:53 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2D111E818D for ; Wed, 31 Jul 2013 06:49:53 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id dn14so1360863obc.40 for ; Wed, 31 Jul 2013 06:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qWxxDx4/6YE685IQJsEorC5freEvbBJrL+SsoGP47p8=; b=i1O2gYyxABc+XyqfP0f+otiPHM/qwqqx7AYk3LPHQgn57ajxuD04lNmk8gLf4aYLhw g3+/GWwhneaeLZpa9ux6THYEG0ywNT3542zKOad3WaWCPAW/GmrBiCG3pB6PEmJDLZxZ 1049Sp5izdbKDz/GDFx2sZ8LQEjR3WTzRbWpFMekEtDHsR/+X+GqG12Y0c5Zg/giKpRH mqSfh4OUvcSiI7LAgRYFJCQPDUsGx9UlATkg9E28Y274iADnFIRixLd9YrE0q38i+ZPZ k+I9/VO0bJ0nQWBEl575a/A+E/tOmvBRRnR61IeUBVgy2hCzeIJBK6Vk9N8yOhfBGj8v iYNg== MIME-Version: 1.0 X-Received: by 10.42.52.6 with SMTP id h6mr22487926icg.5.1375278592697; Wed, 31 Jul 2013 06:49:52 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Wed, 31 Jul 2013 06:49:52 -0700 (PDT) In-Reply-To: <51F91539.4050801@stpeter.im> References: <20130731115043.24006.31384.idtracker@ietfa.amsl.com> <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> <51F90556.5020205@stpeter.im> <3DCA5279-6E44-48EE-BB64-6F3C3C91AB8C@viagenie.ca> <51F91539.4050801@stpeter.im> Date: Wed, 31 Jul 2013 15:49:52 +0200 Message-ID: From: Ted Hardie To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=20cf3036361ffc2be704e2ceff5b Cc: "urn@ietf.org" , Barry Leiba Subject: Re: [urn] NID registration policy X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:49:54 -0000 --20cf3036361ffc2be704e2ceff5b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 31, 2013 at 3:46 PM, Peter Saint-Andre wrote: > > Also, note that Expert Review could require documentation that doesn't > necessarily take the form of "a permanent and readily available public > specification" as in Specification Required. Thus we're not saying that > no documentation would be necessary. > > Do you refer to the case where a document is provided to the expert, but is not available for general review because of license, fee, or similar restriction? Ted > Peter > --20cf3036361ffc2be704e2ceff5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 31, 2013 at 3:46 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

Also, note that Expert Review could require documentation that doesn't<= br> necessarily take the form of "a permanent and readily available public=
specification" as in Specification Required. Thus we're not saying= that
no documentation would be necessary.

<= br>Do you refer to the case where a document is provided to the expert, but= is not available for general review because of license, fee, or similar re= striction?

Ted

=A0
Peter
--20cf3036361ffc2be704e2ceff5b-- From stpeter@stpeter.im Wed Jul 31 07:06:18 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22F721F9CEA for ; Wed, 31 Jul 2013 07:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9npAD5hsmY1 for ; Wed, 31 Jul 2013 07:06:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3070121E813D for ; Wed, 31 Jul 2013 07:05:41 -0700 (PDT) Received: from che-vpn-cluster-2-456.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6B99540046; Wed, 31 Jul 2013 08:07:55 -0600 (MDT) Message-ID: <51F919B2.2060306@stpeter.im> Date: Wed, 31 Jul 2013 16:05:38 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ted Hardie References: <20130731115043.24006.31384.idtracker@ietfa.amsl.com> <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> <51F90556.5020205@stpeter.im> <3DCA5279-6E44-48EE-BB64-6F3C3C91AB8C@viagenie.ca> <51F91539.4050801@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" , Barry Leiba Subject: Re: [urn] NID registration policy X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:06:18 -0000 On 7/31/13 3:49 PM, Ted Hardie wrote: > On Wed, Jul 31, 2013 at 3:46 PM, Peter Saint-Andre > wrote: > > > Also, note that Expert Review could require documentation that doesn't > necessarily take the form of "a permanent and readily available public > specification" as in Specification Required. Thus we're not saying that > no documentation would be necessary. > > > Do you refer to the case where a document is provided to the expert, but > is not available for general review because of license, fee, or similar > restriction? In this context I refer only to RFC 5226: Expert Review (or Designated Expert) - approval by a Designated Expert is required. The required documentation and review criteria for use by the Designated Expert should be provided when defining the registry. For example, see Sections 6 and 7.2 in [RFC3748]. Under that policy, it would be up to us to define what documentation might be required. The case you mention might arise, however (e.g., we know that some URN namespace "managers" have had internal procedures and it might be appropriate for the designated experts to take a look at the relevant documentation to make sure that the namespace manager has good processes and procedures in place). Peter -- Peter Saint-Andre https://stpeter.im/ From barryleiba.mailing.lists@gmail.com Wed Jul 31 07:12:18 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0C111E819E for ; Wed, 31 Jul 2013 07:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.974 X-Spam-Level: X-Spam-Status: No, score=-101.974 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5kYHAMQT32J for ; Wed, 31 Jul 2013 07:12:18 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0B25D11E81A7 for ; Wed, 31 Jul 2013 07:12:15 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id jz10so811503veb.12 for ; Wed, 31 Jul 2013 07:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9B59GoEayKEi/cLNuAkY7kUCPamMQ8LDvvlygORKqN8=; b=pcZkkVdi7hoTpJn5C0aCVUxpgws7nyla99l+SZPnohevJFqnzR+sYgA+nocOCjBmj9 Fpnqipw4ao2aFYVyBFanUsAEn9aEzOhc51cDmj8VTmWVdrFSKIa7JHXiGWyk5v18CZMR o+xjLsy4bJcUbUwUAfEqtS3PRwNDXAntwGVhC2qMEgWrcyH3oK0/tiqQyHx4fyjWmD3O BEoVfjiGaGFwXiM5AC+kQvKTluJB0KXCPj6yKJKXjkKTvMENmm3X17I00o92jphyarsP t6kO8wm6eoStTj4Gil22pUOvCePWRyY2lJnSVz2NMUOC+T688Il+xh04aVJ0diZeAS8m Mutw== MIME-Version: 1.0 X-Received: by 10.58.200.73 with SMTP id jq9mr28924854vec.53.1375279934930; Wed, 31 Jul 2013 07:12:14 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Wed, 31 Jul 2013 07:12:14 -0700 (PDT) In-Reply-To: <51F919B2.2060306@stpeter.im> References: <20130731115043.24006.31384.idtracker@ietfa.amsl.com> <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> <51F90556.5020205@stpeter.im> <3DCA5279-6E44-48EE-BB64-6F3C3C91AB8C@viagenie.ca> <51F91539.4050801@stpeter.im> <51F919B2.2060306@stpeter.im> Date: Wed, 31 Jul 2013 10:12:14 -0400 X-Google-Sender-Auth: 6ZKzWErAv2JSby09a_mDXsPPGTk Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "urn@ietf.org" Subject: Re: [urn] NID registration policy X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:12:18 -0000 >> Do you refer to the case where a document is provided to the expert, but >> is not available for general review because of license, fee, or similar >> restriction? > > In this context I refer only to RFC 5226: > > Expert Review (or Designated Expert) - approval by a Designated > Expert is required. The required documentation and review > criteria for use by the Designated Expert should be provided > when defining the registry. For example, see Sections 6 and > 7.2 in [RFC3748]. > > Under that policy, it would be up to us to define what documentation > might be required. That sort of documentation is usually in the form of the "registration template", which provides additional documentation that's not in the registry. But, that said, ... > The case you mention might arise, however (e.g., we know that some URN > namespace "managers" have had internal procedures and it might be > appropriate for the designated experts to take a look at the relevant > documentation to make sure that the namespace manager has good processes > and procedures in place). ... I think this would be a reasonable approach, in a case where, say, the processes are considered by the expert, but they are not immutable and could change at any time (so they don't fit the definition of "stable" in Specification Required). The DE would have to judge whether the namespace managers are likely to go off the deep end or remain sane for the foreseeable future. Barry From marc.blanchet@viagenie.ca Wed Jul 31 09:08:07 2013 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F6321F9FED for ; Wed, 31 Jul 2013 09:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szCm+BIcUwF5 for ; Wed, 31 Jul 2013 09:08:07 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E887A21F9FE9 for ; Wed, 31 Jul 2013 09:08:06 -0700 (PDT) Received: from h195.viagenie.ca (h195.viagenie.ca [206.123.31.195]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1369940415; Wed, 31 Jul 2013 12:08:05 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: Date: Wed, 31 Jul 2013 18:08:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <851BAC9A-BCE7-47E3-A25F-51FD2E7153B8@viagenie.ca> References: <20130731115043.24006.31384.idtracker@ietfa.amsl.com> <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> <51F90556.5020205@stpeter.im> <3DCA5279-6E44-48EE-BB64-6F3C3C91AB8C@viagenie.ca> <51F91539.4050801@stpeter.im> <51F919B2.2060306@stpeter.im> To: Barry Leiba X-Mailer: Apple Mail (2.1508) Cc: "urn@ietf.org" Subject: Re: [urn] NID registration policy X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 16:08:07 -0000 Le 2013-07-31 =E0 16:12, Barry Leiba a =E9crit = : >>> Do you refer to the case where a document is provided to the expert, = but >>> is not available for general review because of license, fee, or = similar >>> restriction? >>=20 >> In this context I refer only to RFC 5226: >>=20 >> Expert Review (or Designated Expert) - approval by a Designated >> Expert is required. The required documentation and review >> criteria for use by the Designated Expert should be = provided >> when defining the registry. For example, see Sections 6 = and >> 7.2 in [RFC3748]. >>=20 >> Under that policy, it would be up to us to define what documentation >> might be required. >=20 > That sort of documentation is usually in the form of the "registration > template", which provides additional documentation that's not in the > registry. But, that said, ... >=20 >> The case you mention might arise, however (e.g., we know that some = URN >> namespace "managers" have had internal procedures and it might be >> appropriate for the designated experts to take a look at the relevant >> documentation to make sure that the namespace manager has good = processes >> and procedures in place). >=20 that was what I had in mind. show by a document (that should be really a = specification about how the organisation will allocate/manage the = subtree and related topics) to the expert.=20 > ... I think this would be a reasonable approach, in a case where, say, > the processes are considered by the expert, but they are not immutable > and could change at any time (so they don't fit the definition of > "stable" in Specification Required). The DE would have to judge > whether the namespace managers are likely to go off the deep end or > remain sane for the foreseeable future. +1. marc. >=20 > Barry > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn