Subject: [urn] Request for review and comments draft-ietf-urnbis-rfc2141bis-urn-16

From: John C Klensin <[email-masked]>
Date: Sun, 17 Apr 2016 23:00:39 -0400

Hi.

I've posted -ietf-urnbis-rfc2141bis-urn-16.  The major changes
are summarized in the Change Log (Appendix F.8) but the
following (in no particular order) may be worth special note by
the WG.

(1) Versions up to and including -15 contained a good deal of
text that was incremental from RFC 2141 and explained on that
basis.  This version removes that text, making the document much
more of the standalone definition of URNs that the WG is
expected to produce.  The explanations of differences and
increments have been moved to the "changes from..." appendices
(Appendix B and C) and some additional explanation has been
added to an expanded Introduction.

(2) Section 2 ("URN Syntax") has been edited to remove material
that was redundant with other parts of that section or the
document.

(3) Following up the comments on the list, the "resolverID"
material has been removed, the explanation of r-component
reduced to a discussion of the general principle, and a
statement added to indicate that r-components are reserved for
future standardization.

(4) There were a few places where the text assumed knowledge
that, given the 3986 model of URIs, a URN processor might well
not have, with whether or not a particular target resource would
accept a query as one example.  Those statements have been
revised.  The intent of the current language is that, if the URN
resolves to a URL, the q-component and f-component are to be
copied to the URL.  If the URN is an abstract designator or
resolves to something other than a URL, the behavior or those
two components is not defined by the spec -- there just isn't a
lot we can say.  If the language does not make that approach
adequately clear, or if you think another approach would be more
appropriate, please explain why and, if possible, suggest
alternate text.

(5) As I mentioned in an earlier note, RFC 3506 contains a
subsection titled "process for identifier resolution".   I
believe that Section 6.4.6 and the registration template of
2141bis-16 adequately captures what was there, while removing
the specific reference to DDDS.  The model in the current draft
is intended to be that, if the URN and namespace are not for an
abstract designator (i.e., the URN is expected to "resolve"
somehow, independent of what "resolve" means (see the discussion
in Sections 1.1 and 1.2 for that topid) then the registration
template and process are expected to either:

	(i) Specify the resolution tools and/or procedure and
	any additional information needed to utilize it or them.
	
	(ii) Specify a resolution discovery system (RDS) that
	will provide the needed information and any information
	needed to call on and use that system.

As above, if that is not clear from the text in -16 or if you
disagree with the approach and have something new to say on the
subject (please see ;
cent note as well as my prior one), please speak up soon and, if
you simply have a problem with the explanation, supply
recommended text if possible.  As mentioned in an earlier note,
I think there is a role for a model in which a persistent object
or resource identifier is passed to an explicitly-specified
resolution service, but that is not a URN as we have so far
known it,   

(6) Finally, there is a question about component syntax.  Our
current hypothesis is that we need only q-components,
f-components, and r-components, even though we don't have a
clear understanding of the latter.  The q-components and
r-components are introduced by "?=" and "?+" only.  Each one
(along with "#") terminates the other, but all other sequences
consisting on "?" followed by something else are normal -- they
can appear inside q-component or r-component strings, or
elsewhere, without any special interpretation (or requiring
quoting).  If we are sure that we won't need anything else, that
is fine.  However, if we were somehow concerned that we might
need additional component types and corresponding delimiters,
this is probably our last chance to make provision for that
without having to make major incompatible changes.  Anyone want
to make a strong case for making such reservations?

Of course, I may have missed other issues, but those are the
ones I'm aware of at present.  I think that, if the WG can check
them and either agree they are ok or focus on what else might be
done, we should be just about finished.   There are still some
typographical and editorial issues with this draft which we will
get to next time... if you find any, please say so.

thanks,
   john (with a lot of help from Peter this time, but the errors
are certainly mine)
,

\

---

From: "Hakala, Juha E" <[email-masked]>
Date: Thu, 21 Apr 2016 06:57:07 +0000

Hello John; all, 

this new version of rfc2141bis is an improvement, and I believe we are getting closer to the goal of this process. 

I am fine with the decision to postpone work on r-component, although that means further delay of some development projects the library community has been talking about. 

There are some minor issues in the text that should be corrected. 

In 2.3.1 the draft says: 

"If a URN resolves to a URL, the q-component from the URN is copied verbatim to the query component of the URL."

However, we are no longer using URI query component syntax and our added "=" may cause problems. It is probably better to say something like:

"If a URN resolves to a URL, the q-component from the URN is copied to the query component of the URL without "=", so that the query syntax matches URI query component."  
  
In 2.3.3 there is a paragraph

"Clients SHOULD NOT pass f-components to resolution services unless those services also perform object retrieval and interpretation functions."

The purpose of this is to allow the resolution service to act as a "client" which retrieves the entire identified object, applies the fragment to it and sends the result to the original client. IMO this would often give no added value. If the only purpose of the fragment is to take the user to a certain point within the document, there is no way the resolver can do this on behalf of the client the customer is using. So even if the fragment were included in the URN, the resolver should just ignore it, and pass the entire document to the client which then applies the fragment to it. 

On the other hand, clients usually do not send fragments to servers / resolvers, so it might be non-trivial to change this behavior even if the resolver could do something meaningful with fragments. 

The easiest solution is to just write 

Clients SHOULD NOT pass f-components to resolution services functions even if those services also perform object retrieval and interpretation functions."

since then there is no pressure to change the normal behavior of clients, or to add entirely new kind of functionality to resolvers, which in the end of the day might not be that useful.

In 4.2 there is a somewhat challenging (at least for a non-English speaker) sentence

"In part because of the separation of URN semantics from more general
   URI syntax [I-D.ietf-urnbis-semantics-clarif], generic URI processors
   need to pay special attention to the parsing and analysis rules of
   RFC 3986 and, in particular, must treat the URI as opaque unless the
   scheme and its requirements are recognized."

It might be better to say something like "... must treat the URN as opaque unless the identifier scheme is recognized and its requirements are known and met."

Chapter 5 specifies three constraints: uniqueness, consistent assignment and assignment according to a common definition. I would like to add fourth constraint, persistence. It is already there between the lines (URN is never reassigned to a different resource) but we could also make the point that sometimes URNs may even outlive identified resources.

There is a typo in 6.4.6: handilng should be handling. 

Finally, I am OK with the idea of having two kinds of URNs: resource identifiers and abstract designators which do not and will not support resolution services. But I find it difficult to accept (as stated in Introduction) that these abstract designators, although persistent, do not identify a resource. What is the purpose of a URN that does not identify anything? It is definitely possible to identify something without being resolvable.    

All the best, 

Juha

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of John C Klensin
> Sent: 18. huhtikuuta 2016 6:01
> To: [email-masked]
> Subject: [urn] Request for review and comments draft-ietf-urnbis-
> rfc2141bis-urn-16
> 
> Hi.
> 
> I've posted -ietf-urnbis-rfc2141bis-urn-16.  The major changes are
> summarized in the Change Log (Appendix F.8) but the following (in no
> particular order) may be worth special note by the WG.
> 
> (1) Versions up to and including -15 contained a good deal of text that was
> incremental from RFC 2141 and explained on that basis.  This version
> removes that text, making the document much more of the standalone
> definition of URNs that the WG is expected to produce.  The explanations of
> differences and increments have been moved to the "changes from..."
> appendices (Appendix B and C) and some additional explanation has been
> (2) Section 2 ("URN Syntax") has been edited to remove material that was
> redundant with other parts of that section or the document.
> 
> material has been removed, the explanation of r-component reduced to a
> discussion of the general principle, and a statement added to indicate that r-
> components are reserved for future standardization.
> 
> (4) There were a few places where the text assumed knowledge that, given
> the 3986 model of URIs, a URN processor might well not have, with whether
> or not a particular target resource would accept a query as one example.
> Those statements have been revised.  The intent of the current language is
> that, if the URN resolves to a URL, the q-component and f-component are to
> be copied to the URL.  If the URN is an abstract designator or resolves to
> something other than a URL, the behavior or those two components is not
> defined by the spec -- there just isn't a lot we can say.  If the language does
> not make that approach adequately clear, or if you think another approach
> would be more appropriate, please explain why and, if possible, suggest
> alternate text.
> 
> 2141bis-16 adequately captures what was there, while removing the specific
> reference to DDDS.  The model in the current draft is intended to be that, if
> the URN and namespace are not for an abstract designator (i.e., the URN is
> expected to "resolve"
> somehow, independent of what "resolve" means (see the discussion in
> Sections 1.1 and 1.2 for that topid) then the registration template and
> process are expected to either:
> 
> As above, if that is not clear from the text in -16 or if you disagree with the
> approach and have something new to say on the subject (please see ; cent
> note as well as my prior one), please speak up soon and, if you simply have a
> problem with the explanation, supply recommended text if possible.  As
> mentioned in an earlier note, I think there is a role for a model in which a
> persistent object or resource identifier is passed to an explicitly-specified
> (6) Finally, there is a question about component syntax.  Our current
> hypothesis is that we need only q-components, f-components, and r-
> components, even though we don't have a clear understanding of the latter.
> The q-components and r-components are introduced by "?=" and "?+" only.
> Each one (along with "#") terminates the other, but all other sequences
> consisting on "?" followed by something else are normal -- they can appear
> inside q-component or r-component strings, or elsewhere, without any
> special interpretation (or requiring quoting).  If we are sure that we won't
> need anything else, that is fine.  However, if we were somehow concerned
> that we might need additional component types and corresponding
> delimiters, this is probably our last chance to make provision for that
> without having to make major incompatible changes.  Anyone want to make
> a strong case for making such reservations?
> 
> Of course, I may have missed other issues, but those are the ones I'm aware
> of at present.  I think that, if the WG can check them and either agree they
> are ok or focus on what else might be
> typographical and editorial issues with this draft which we will get to next
> time... if you find any, please say so.
> 
> thanks,
>    john (with a lot of help from Peter this time, but the errors are certainly
> mine) ,
> 
> \
> 
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: John C Klensin <[email-masked]>
Date: Thu, 21 Apr 2016 13:29:53 -0400

Juha,

Thanks for the careful reading.  A few comments inline below.

--On Thursday, April 21, 2016 06:57 +0000 "Hakala, Juha E"
<[email-masked]> wrote:

> Hello John; all, 
> 
> this new version of rfc2141bis is an improvement, and I
> believe we are getting closer to the goal of this process. 
> 
> I am fine with the decision to postpone work on r-component,
> although that means further delay of some development projects
> the library community has been talking about. 

Speaking personally (not as editor), I'd like to understand
those projects, particularly the needs they are trying to
address, in more detail.  That should, however, probably be
off-list or delayed until we've gotten 2141bis and its relatives
finished.

> "If a URN resolves to a URL, the q-component from the URN is
> copied verbatim to the query component of the URL."
> 
> However, we are no longer using URI query component syntax and
> our added "=" may cause problems. It is probably better to say
> something like:
> 
> "If a URN resolves to a URL, the q-component from the URN is
> copied to the query component of the URL without "=", so that
> the query syntax matches URI query component."     

I actually checked that sentence when I rewrote things for the
"?=" convention and I believe it is correct.    The reason is
that, in the ABNF (and I hope consistently in the text), the
q-component is consistently the string without the introducer.
For example, Section 2 of 2141bis-16 includes

      rq-components =  ( "?="  q-component
                          [ "?+" r-component ] ) /
                       ( "?+" r-component
                          [ "?="  q-component ] )
      q-component   = pchar *( pchar / "/" / "?" )

That is consistent with the way <query> is defined in 3968,
i.e., from Section 3 of that document:

    URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

So copying the q-component (which does not include the "?=")
into the query (which does not contain the "?") actually is
correct.  I have doubts about whether "verbatim" is actually
helpful, but that is another issue.

If you and others think it would be helpful, it would be fairly
easy to incorporate a sentence into the paragraph after the
2141bis syntax partially quoted above and/or after the "copied"
sentence warning that "q-component", etc., refer to the string
and do not contain the introducing delimiter.  An even better
solution might be to incorporate an example if someone wants to
suggest one.

> "Clients SHOULD NOT pass f-components to resolution services
> unless those services also perform object retrieval and
> interpretation functions."
> 
> The purpose of this is to allow the resolution service to act
> as a "client" which retrieves the entire identified object,
> applies the fragment to it and sends the result to the
> original client. IMO this would often give no added value. If
> the only purpose of the fragment is to take the user to a
> certain point within the document, there is no way the
> resolver can do this on behalf of the client the customer is
> using. So even if the fragment were included in the URN, the
> resolver should just ignore it, and pass the entire document
> to the client which then applies the fragment to it. 

Actually, the reason for it was a little different and that is
to not constrain implementation models.  In one resolution model
(using the URN-> URL case as the obvious example), the one I
think you have in mind, the approach is 

    client parses URN into pieces and 
    client sends NID and NSS 
           -> URN-resolution-service
           <-   (resulting URL)
       -or-  sends NSS 
           -> NID-specific resolution-service
           <-  (resulting URL) 
           
    client adds whatever needs to be added to URL
    client -> URL-resolution-service
           <-  (resulting resource/ object)
    client evaluates fragment, if any, against object
    client returns object, or object subset, to user

The other model, which I think is worth preserving, is 

    client does not parse URN but 
        passes the whole thing 
            -> URN processor
            <- (resulting resource / object and
                fragment ID
    client evaluates fragment, if any, against object
    clients returns object, object subset, or other 
        result to user.

There are several variations on those themes, but the basic
difference in that, in the first model, the client has to break
the URI into pieces and then manage the processing/ evaluation
of the pieces.  In the second, most of that is handed off to
what looks to the client like a black box that emits a resource
or, in extreme cases, conformation that the desired action has
been completed.  

In addition to suggesting two different processing models,
either of which might be implemented in libraries or the like
for a broad range of URNs, the relationship between the two also
suggests a distinction that 2141bis does not make.  That
specification now describes two types of URNs, those that
resolve in some way (for some very broad definition of
"resolve") and those that do not resolve at all, with the latter
called "abstract designators".   It is also possible to
distinguish between namespaces of "objects" that are similar to
documents and "objects" that are really actions to be performed.
The latter would strongly favor the second implementation model
(as well as concepts closer to some views of what r-components
should be about).   The distinction has not been made in 2141bis
for a number of reasons, including its non-discussion in the WG
and some concern, reflected in a different form in my recent
note to Sean, as to whether such creatures should be considered
as URNs or perhaps as URAs ("... resource actions"?) or
individual URI schemes.

> On the other hand, clients usually do not send fragments to
> servers / resolvers, so it might be non-trivial to change this
> behavior even if the resolver could do something meaningful
> with fragments. 

Yes.  Indeed, 3986 can be read as prohibiting anything but the
client from doing anything at all with fragments.   On the other
hand, interpreting 3986 that way may violate the principle that
Internet standards specify what happens (and is visible "on the
wire") rather than where and how it is done.

> Clients SHOULD NOT pass f-components to resolution services
> functions even if those services also perform object retrieval
> and interpretation functions."

> since then there is no pressure to change the normal behavior
> of clients, or to add entirely new kind of functionality to
> resolvers, which in the end of the day might not be that
> useful.

I can live with that although I believe the restriction is
unnecessary and might, in some edge cases, might be harmful.
Need to hear from others about this.

> "In part because of the separation of URN semantics from more
> general    URI syntax [I-D.ietf-urnbis-semantics-clarif],
> generic URI processors    need to pay special attention to the
> parsing and analysis rules of    RFC 3986 and, in particular,
> must treat the URI as opaque unless the    scheme and its
> requirements are recognized."
> 
> It might be better to say something like "... must treat the
> URN as opaque unless the identifier scheme is recognized and
> its requirements are known and met."

I wonder.  Noting that 3986 uses a definition of "identifier"
that you and others have questioned and that it doesn't use the
term "identifier scheme" at all, might this just add confusion?
In 3986-speak, the scheme associated with (or part of) the
identifier is well defined and, for the purposes of 2141bis, is
always "urn" unless we are specifically talking about URIs, I'm
not even sure how to read your modified sentence.

What that admittedly-difficult sentence is trying to say is
closer to:

	'If one has a generic processor for URI, the rules of
	3986 apply and must be followed.  Only if the processor
	recognizes the "urn" scheme and understands the
	applicability of this specification as a result it is
	appropriate to try to apply its extended rules.'

Put that way, the statement is very nearly tautologically
trivial and should simply be dropped.  But I think we added it
to help define the "syntax only but, like other schemes, we get
to further restrict and interpret the syntax" boundary between
2141bis and 3986.  Suggestions welcome.

> Chapter 5 specifies three constraints: uniqueness, consistent
> assignment and assignment according to a common definition. I
> would like to add fourth constraint, persistence. It is
> already there between the lines (URN is never reassigned to a
> different resource) but we could also make the point that
> sometimes URNs may even outlive identified resources.

Send text.  I can't remember whether it was an explicit decision
or not, but persistence may have been omitted from Section 5
after it became necessary to add what is now Section 1.1 to
reflect the fact that we couldn't really agree on a
universally-applicable definition for persistence.   Of course,
we could simply insert a persistence constraint to Section 5 and
point back to 1.1 for a [non-]definition.
  
> There is a typo in 6.4.6: handilng should be handling. 

Fixed in working draft for -17.  Thanks.

> Finally, I am OK with the idea of having two kinds of URNs:
> resource identifiers and abstract designators which do not and
> will not support resolution services. But I find it difficult
> to accept (as stated in Introduction) that these abstract
> designators, although persistent, do not identify a resource.
> What is the purpose of a URN that does not identify anything?
> It is definitely possible to identify something without being
> resolvable.    

First of all, I agree that things are still a little bit
confused (see discussion above).  I am hoping that complete
clarification is not in the critical path.   But the specific
answer to your question is that we've got several situations
(the XMPP one is the most-cited case) in which the presence or
absence of a URN, or the presence of a URN with a particular set
of values in the NSS, simply tells whatever (e.g., client) is
interpreting it to take or not take some action or to behave in
one way or not another.   For some months, I referred to such
URNs as "indicators" (sometimes prefixed by "pure" or
"abstract") to distinguish them from "identifiers" in the sense
that your comments above implied.  There are some disadvantages
to the "indicator" terminology.  While I don't remember an
explicit discussion of that terminology, Peter preferred
"abstract designator", no one else seemed to object, and I
didn't think it was worth arguing about.  If you see a useful
way to clarify that situation, please suggest it.

thanks again,
    john

---

From: "Hakala, Juha E" <[email-masked]>
Date: Mon, 25 Apr 2016 10:18:21 +0000

Hello John; all, 

Further comments below. 

> From: John C Klensin [mailto:[email-masked]]
> Sent: 21. huhtikuuta 2016 20:30
> To: Hakala, Juha E <[email-masked]>; [email-masked]
> Subject: RE: [urn] Request for review and comments draft-ietf-urnbis-
> rfc2141bis-urn-16
> 
> Juha,
> 
> > this new version of rfc2141bis is an improvement, and I believe we are
> > getting closer to the goal of this process.
> >
> > I am fine with the decision to postpone work on r-component, although
> > that means further delay of some development projects the library
> > community has been talking about.
> 
> Speaking personally (not as editor), I'd like to understand those projects,
> particularly the needs they are trying to address, in more detail.  That
> should, however, probably be off-list or delayed until we've gotten 2141bis
> and its relatives finished.

In short, resolvers must be made a lot smarter. All PIDs are facing the same problem. Future resolvers must offer more options to the users instead of just supporting persistent linking to the identified resource. Improvements in systems with which libraries, publishers etc. are managing digital resources both enable and require such improvements in resolvers. Currently our (and for instance publishers') applications are not too smart, but things will change in few years' time, and URN syntax should be ready to accommodate these new requirements when they materialize.  

For instance, when a future user locates a relevant document, she should be able to easily retrieve rights metadata (copyright owner, license terms etc.) related to the document. It would be easy to list many other requirements and functionalities which have to do with metadata (descriptive / administrative / structural) about digital objects.   

> > "If a URN resolves to a URL, the q-component from the URN is copied
> > verbatim to the query component of the URL."
> >
> > However, we are no longer using URI query component syntax and our
> > added "=" may cause problems. It is probably better to say something
> > like:
> >
> > "If a URN resolves to a URL, the q-component from the URN is copied to
> > the query component of the URL without "=", so that
> that, in the ABNF (and I hope consistently in the text), the q-component is
> consistently the string without the introducer.

OK. I missed that. But it might be a good idea to minimize the chance that others make the same mistake.

> That is consistent with the way <query> is defined in 3968, i.e., from Section
> 3 of that document:
> 
> So copying the q-component (which does not include the "?=") into the query
> (which does not contain the "?") actually is correct.  I have doubts about
> whether "verbatim" is actually helpful, but that is another issue.
> 
> If you and others think it would be helpful, it would be fairly easy to
> incorporate a sentence into the paragraph after the 2141bis syntax partially
> quoted above and/or after the "copied"
> sentence warning that "q-component", etc., refer to the string and do not
> contain the introducing delimiter.  An even better solution might be to
> incorporate an example if someone wants to suggest one.

Such sentence + an example would be useful. 

An example can be built by pre-using the example further down in the text: 

urn:example:weather?=op=map&lat=39.56
         &lon=-104.85

could be resolved to something like

https://weatherapp.org?op=map&lat=39.56
         &lon=-104.85
 
> > "Clients SHOULD NOT pass f-components to resolution services unless
> > those services also perform object retrieval and interpretation
> > functions."
> >
> > The purpose of this is to allow the resolution service to act as a
> > "client" which retrieves the entire identified object, applies the
> > fragment to it and sends the result to the original client. IMO this
> > would often give no added value. If the only purpose of the fragment
> > is to take the user to a certain point within the document, there is
> > no way the resolver can do this on behalf of the client the customer
> > is using. So even if the fragment were included in the URN, the
> > resolver should just ignore it, and pass the entire document to the
> > client which then applies the fragment to it.
> 
> Actually, the reason for it was a little different and that is to not constrain
> implementation models.  In one resolution model (using the URN-> URL
> case as the obvious example), the one I think you have in mind, the approach
> is
> 
> There are several variations on those themes, but the basic difference in
> that, in the first model, the client has to break the URI into pieces and then
> manage the processing/ evaluation of the pieces.  In the second, most of
> that is handed off to what looks to the client like a black box that emits a
> resource or, in extreme cases, conformation that the desired action has been
> completed.
> 
> In addition to suggesting two different processing models, either of which
> might be implemented in libraries or the like for a broad range of URNs, the
> relationship between the two also suggests a distinction that 2141bis does
> not make.  That specification now describes two types of URNs, those that
> distinguish between namespaces of "objects" that are similar to documents
> and "objects" that are really actions to be performed.

I cannot see any immediate use for utilizing identifiers for actions like this, at least in library domain, but eventually such approach may become relevant. 

> The latter would strongly favor the second implementation model (as well
> as concepts closer to some views of what r-components
> for a number of reasons, including its non-discussion in the WG and some
> concern, reflected in a different form in my recent note to Sean, as to
> whether such creatures should be considered as URNs or perhaps as URAs
> ("... resource actions"?) or individual URI schemes.
> 
> > On the other hand, clients usually do not send fragments to servers /
> > resolvers, so it might be non-trivial to change this behavior even if
> > the resolver could do something meaningful with fragments.
> 
> hand, interpreting 3986 that way may violate the principle that Internet
> standards specify what happens (and is visible "on the
> > Clients SHOULD NOT pass f-components to resolution services functions
> > even if those services also perform object retrieval and
> > since then there is no pressure to change the normal behavior of
> > clients, or to add entirely new kind of functionality to resolvers,
> > which in the end of the day might not be that useful.
> 
> I can live with that although I believe the restriction is unnecessary and
> might, in some edge cases, might be harmful.

Now that I understand the purpose of the text, I take back my suggestion. Let's keep the current formulation. 
> > It might be better to say something like "... must treat the URN as
> > opaque unless the identifier scheme is recognized and its requirements
> > are known and met."
> 
> that you and others have questioned and that it doesn't use the term
> "identifier scheme" at all, might this just add confusion?
> In 3986-speak, the scheme associated with (or part of) the identifier is well
> defined and, for the purposes of 2141bis, is always "urn" unless we are
> specifically talking about URIs, I'm not even sure how to read your modified
> sentence.
> 
> What that admittedly-difficult sentence is trying to say is closer to:
> 
> Put that way, the statement is very nearly tautologically trivial and should
> simply be dropped.  But I think we added it to help define the "syntax only
> but, like other schemes, we get to further restrict and interpret the syntax"
> boundary between 2141bis and 3986.  Suggestions welcome.

I should not have used the term "identifier scheme". What I was aiming at was that parsing a URN is a double challenge for a generic URI processor. First, the processor must recognize the "urn" scheme. And next, the processor must know how to deal with identifier system (URN namespace). A parser capable of resolving urn:isbn's may not know itself how to deal with urn:issn's. In an ideal world equipped with resolver discovery service, urn:isbn resolver would know how to find the urn:issn resolver or any other urn namespace specific resolver out there. For the time being, finding the right resolver (there may be several for a single namespace) can be a challenge unless the resolver location is embedded in the URI with the URN.

Parsing URNs is to some extent namespace specific . Some namespaces may not provide any services, some may have a whole set of them. "Scheme-appropriate processing" seems to relate to URNs in general. Recognizing that a string is a URN is the necessary first step, but from practical point of view it is more important to provide appropriate namespace specific parsing of URNs.    

> > assignment and assignment according to a common definition. I would
> > like to add fourth constraint, persistence. It is already there
> > between the lines (URN is never reassigned to a different resource)
> > but we could also make the point that sometimes URNs may even outlive
> > identified resources.
> 
> Send text.  I can't remember whether it was an explicit decision or not, but
> persistence may have been omitted from Section 5 after it became
> necessary to add what is now Section 1.1 to reflect the fact that we couldn't
> really agree on a
> we could simply insert a persistence constraint to Section 5 and point back
> to 1.1 for a [non-]definition.

What about this formulation to replace the current requirement 1 in chapter 5: 

The "uniqueness" and "persistence" constraints mean that once assigned, an identifier within the
       namespace is never altered and never reassigned to a different resource (for the kind of "resource"
       identified by URNs assigned within the namespace) even If the URN is found to have been issued in error. This holds
       true even if the identifier itself is deprecated or becomes obsolete.

Note that I am not comfortable with "identifier within the namespace is never assigned to more than one resource ". In ISBN namespace, for instance, there are separate ISBNs for all three parts of The Lord of the Rings, but there is also 4th ISBN which covers all three parts. So ISBN namespace does not meet the requirement "never assigned to more than one resource", since in the ISBN namespace the concept of book is complex and covers both multivolume works as single entity in addition to each volume.   

> > resource identifiers and abstract designators which do not and will
> > not support resolution services. But I find it difficult to accept (as
> > stated in Introduction) that these abstract designators, although
> > persistent, do not identify a resource.
> First of all, I agree that things are still a little bit confused (see discussion
> above).  I am hoping that complete
> clarification is not in the critical path. 

I don't think so. 

  But the specific
> answer to your question is that we've got several situations (the XMPP one
> is the most-cited case) in which the presence or absence of a URN, or the
> presence of a URN with a particular set of values in the NSS, simply tells
> whatever (e.g., client) is interpreting it to take or not take some action or to
> behave in
> "abstract") to distinguish them from "identifiers" in the sense that your
> comments above implied.  There are some disadvantages to the "indicator"
> terminology.  While I don't remember an explicit discussion of that
> terminology, Peter preferred "abstract designator", no one else seemed to
> object, and I didn't think it was worth arguing about.  If you see a useful way
> to clarify that situation, please suggest it.

I cannot... but I can live with this situation. This part of the spec may become a headache if and when it becomes necessary to translate and explain "abstract designator" in Finnish ;-). 

Best regards, 

Juha