Subject: [urn] Embedded characters in the r-component (was: Re: (urnbis-15 review) the new abnormal: q-component and r-component)

From: John C Klensin <[email-masked]>
Date: Mon, 21 Mar 2016 19:53:44 -0400

--On Sunday, February 21, 2016 13:42 -0800 Sean Leonard
<[email-masked]> wrote:

>> The other issue is what we actually mean by "embedding", and
>> is a more complex question.  So far, the WG has believed that
>> simply delimiting the two substrings is sufficient.  However,
>> if we need to specify that any appearances of "?", or "?="
>> or, most particularly, "?+" in those strings must be
>> %-encoded and then that the URN-parser needs to be able to
>> decode one level of %-encoding before putting the contents of
>> the q-component into a URL as a <query>, it seems to me that
>> is easily accomplished in terms of the document and not a big
>> deal for a URN-parser/evaluator.
> 
> Ok well here we have a substantive difference, that I hope we
> can tease out.

I note (again) that the number of people in the WG who have
responded to this part of your suggest is, AFAICT, zero.   I am
violently opposed to having my text prevail simply because there
is only one objection, so let's indeed try to tease things out a
bit.

> I am not sure that "So far, the WG has believed that simply
> delimiting the two substrings is sufficient." Some in the WG
> have said this (references, please?); my position is that
> delimiting is not sufficient.

Ok.  I have been drawing some inferences from silence, which is
always a dangerous business.  On the other hand, the alternative
to proposing something specific in the draft and notes to the
list appears to be to do nothing until a healthy discussion in
the WG emerges, something that, for these issues, takes either a
long time or considerable stimulation.   Waiting for a
discussion obviously does not work either, especially since
there is some small evidence that the long silences and
inability to resolve issues --issues that some participants are
unconvinced that they should care about-- are driving people
away.

>  As you pointed out: if you
> delimit them with ?= ?+ etc., you must also %-encode the
> constituent parts. This means multiple levels of %-encoding,
> since % encoded characters will themselves get % encoded to
> %25.

Yep.  As I read it, that is what 3986 requires if those
sequences are used inside the component strings.  I can't tell
you what I think about the requirement in polite language,
except that it is a logical and, IMO, inevitable consequence of
other parts of the 3986 definition, but, unless I've missed
something important, it is the requirement.

Do note, however, that 2141bis-15 says that the question mark
can be used without percent-encoding inside q-component and
r-components.  The termination condition is one of the
two-character sequences, not a bare "?" or one followed
immediately by anything else.    I had hoped that was clear from
the syntax and discussion in Section 2 of -15; if it is not, I'd
appreciate pointers and suggestions.  So the scope of "must
%-encode the constituent parts" really applies only to embedded
"?=" in the r-component and "?+" in the q-component.  Again, if
that is not clear, please identify where and make suggestions.

I don't think it is a major issue, but I'd appreciate comments
from anyone who has thought deeply about %-encoding whether,
given those two-character sequences, we would be better off with
a specific requirement to represent "?+" embedded in an
r-component as  %3F%3D (and similarly for q-component and "?=")
or whether we should just leave well enough (and 3986) alone
since %-encoding either "?" or "+" would break up the parsing.

> History has shown that double-encoding things is a security
> disaster. There is a whole class of security vulnerabilities
> where implementations fail to properly double-encode or
> double-decode things. Furthermore, it's just not readable.
> People are going to transcribe these things by-hand too,
> especially for library things.

Yep.  And double-encoding thing is also an implementation
disaster and a pain in various sensitive parts of the anatomy
independent of the security issues.

>>    It would add a bit to the confusion we
>> already have with IRIs and where %-encoding is required and
>> optional, but not very much.    So, while I think we need to
>> straighten out whether that encoding requirement is needed, I
>> don't see the problem as anything near "unworkable".
> 
> If it is conceded that an additional layer of %-encoding is
> required by using ?= and ?+ delimiters (because, as I just
> said, a malicious or otherwise specially crafted q-component
> could contain ?+ thus switching the URN parser into
> r-component-parsing mode), then one also concedes the point
> that the current draft-15 text--which makes no mention of
> additional %-encoding--is "unworkable".

First, I'm not entirely sure I understand the security threat
model associated with "switching... into r-component-parsing
mode".  It seems to me that there are a huge number of ways in
which doing something mildly funky to a URI can cause
unanticipated behavior and even provide the basis for an attack.
I discovered a link on an IETF web page this morning that was
equivalent to www/example.com rather than www.example.com.  When
that link was clicked (because IETF web pages are trustworthy,
right?) my trusty web browser promptly routed me to
http://www.com/A.B.C.D where A.B.C.D are the IP address of the
machine from which I issued the query.  That is apparently a
site where one does not want to end up, especially by accident
and with Javascript and cookies enabled, with or without the
privacy issues of fully exposing an IP address.   We also see
examples equivalent to
http://www.good-site.com.really-evil-site.example/ with great
regularity, often as the first part of really long and complex
URLs.  I can understand the desire to avoid adding to the mess
but, if the community doesn't take either of those examples
seriously, I have trouble getting excited about some possible
problems with "?+", if only because the two examples above are a
lot easier for a bad guy to construct.

In any event, perhaps I am not understanding your point, but I
don't think "?+" and "?=" introduce a new problems, partially
because even the idea of using "?" and "??" either requires some
arbitrary limits on characters that can be used or requires
double-encoding.   One can argue that, in practice, some
approaches will require more double-encoding than others, but
that is speculative.  More broadly, if anything that contain or
requires double-encoding is "unworkable" or worse, the problem
lies with 3986, not 2141bis.  

Stepping back a bit, I suggest the only easy and completely
clean way to deal with these issues would be to have a
single-character introducer for r-component and a
single-character introducer for q-component, with those two
characters being unique wrt each other and anything else with a
potential special meaning in URIs.  If one could do that, then
we could cleanly adopt the one-level model of 3986 and define
the two components as starting with (or after) the relevant
delimiter and continuing to the next relevant (one-character)
delimiter (the other component delimiter, "#", or the end of the
string).   There was a search for such characters and,
unfortunately, 3986 uses or reserves all of them.  The
conclusion from that search and the subsequent discussion was
that any creative use of other, single, characters would violate
3986 (btw, staying out of the way of 3968 is also part of the
argument for restricting resolverIDs to LDH).  IIR, we hadn't
gotten to the q-component / r-component distinction yet, but
those sorts of constraints were a key reason why we proposed
separating URNs from 3986 entirely, an idea that went down in
flames.

After several rounds of the "what are the delimiters and which
comes first" discussion, Andy concluded that the WG had
concluded that two-character introducer sequences were the way
to go and delegated the choice of characters to be used
following "?" to the document editors.   Unless I've
misunderstood something, you are reopening that argument.  I'm
not sure I see anything new in your note, but leave that
question to the WG co-chairs.

>...
> To be clear, ? in q-components is foreseeable...in that
> q-component = any URI query, so ? can appear in the wild.
> I.e., it will appear, especially in deliberately crafted
> payloads.

Yep.   But see above about the absence of any requirement to
encode "?" in q-components unless it is followed immediately by
"+".

> We have control however over r-component, by prohibiting ? or
> mandating that ? be %-encoded as %3F. (These are tantamount to
> the same thing.) There are lots of other delim characters that
> can be imbued with reserved purposes, within an r-component
> production.

Actually, based on the conclusions of people who have stared
even harder at 3986 than I have, "lots of other delim
characters..." is, at best, a significant exaggeration.   The
options are _very_ restricted.

My concern, in part connected to the question of whether the
choice of resolvers can be used to select what information is
returned, rather than only how and maybe where it is looked up,
is that people could easily discover they have a need for
(deliberately avoiding mashing this into URI/URN syntax or
suggesting delimiter structure).

    urn:ietf:rfc:9999
    q-component=     "format=pdf"
    #section 4.1
    r-component=  "urnresolver.ietf.org?contents='congestion
failures'"
    
using the above with the intent of retrieving a copy of the
document in PDF, but only those sections that discuss (or
contain the string) "congestion failures", and then only the
subset of those sections identified as "section 4.1".  A little
far-fetched, but not very far from some of the ways people have
suggested using q-components, r-components, and fragments in
combination.  And, of course, barring something more ingenious
than the WG has been able to come up with so far, that
r-component -- which contains a "3986-query"-style instruction
to the resolver about what to return-- requires an embedded "?"
but not one that is required to be %-encoded.   One could
require a different syntax to express the same thing, but, IMO,
that takes us further into the problem of specifying something
rather precisely for which I believe the WG has shown it doesn't
want to deal.

My recommendation is, again, to take all of that out, relying on
3986 and the two-character starting and ending delimiters. 

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Mon, 21 Mar 2016 20:13:42 -0400

--On Sunday, February 21, 2016 13:22 -0800 Sean Leonard
<[email-masked]> wrote:

>> a discussion, one that is active and focused enough
>> to not hold us up for months debating a few characters for
>> which there is no demonstrated need beyond "we could...".  In
>> defense of that position, I think we should remember that it
>> is much easier to add (allow) a previously-prohibited
>> character if it turns out to be necessary than it is to
>> delete one that turns out to be a problem.
> 
> As an implementer, that is not my position. It is one thing to
> say that a character is "RESERVED"--it's another thing
> entirely to prohibit it in the ABNF.
> 
> Once this thing gets published, people will write code that
> implements the ABNF. You can't add characters so easily.
> 
> The limitation of resolverID to LDH is arbitrary and (as far
> as I can tell, since the discussion has come up) capricious.
> You could say "we could limit it", but you could also easily
> say "we could expand it". Up until now the set of characters
> has not gotten much airplay.

Of course it is both arbitrary and capricious.  I think I
actually said that on-list.  I also asked for comments and
specific suggestions and got nothing.   The choice between
leaving something out of the ABNF and explicitly reserving it is
one we've made in different ways in different IETF protocols
over the years.   I think it is safe to say that neither has
worked really well, at least in part because different
implementers have understood that what they can do differently.
That, in turn, is rooted in the notion that some behavior
(including either using a reserved character or using a
character that is not covered by the ABNF) is simply "outside
the standard", a concept that a number of documents, including
the famous RFC 2119, seem to be a little closer than they are to
identifying implementations as "non-conforming" in those sorts
of cases.  FWIW, 3986 follows one model and 5321 follows that
other.  Opinions differ as to which type of definition has been
more successful.

> If you want to stuff more in the resolverID production than
> LDH, the only way to do it based on the current ABNF in
> draft-15 is Punycode, just like DNS.

Certainly not the only way, and the specific use of the Punycode
algorithm would be a disaster, in part because of other
assumptions it makes.  Use of an ACE would be feasible although
certainly not what I would recommend.  Use of %-encoding works
too and, AFAICT, 3986 makes it impossible to prohibit (whatever
you (or I) think of that encoding).  

However the more important point is the prohibition was
deliberate as was borrowing the RHS from the NID production.
Putting actual characters outside the ASCII range (i.e., octets
with the high-order bit non-zero) into URNs generally would
(again intentionally and, for resolverID, paralleling NID)
require a change in the standard.   If one goes with restrictive
ABNF, them the change is to extend the ABNF.  If one goes with
some "reserved" construction, then the change is to allow the
reserved characters.  With one exception, I don't seem much
difference there _except_ that the RESERVED approach, depending
on how it is written up, probably also requires changes to 3989
because, again, AFAICT, 3986 prohibits _any_  non-ASCII
character except in encoded form.

FWIW, I believe that the WG reached the conclusion that we
didn't want to touch the URI/IRI debate or explicitly
incorporate URNs into the IRI space.  I think the current
structure in the text reflects that conclusion.  I also note a
pragmatic problem: if we want to open up what I guess would be
called IRNs, it would be hard to write the text and be
consistent with other URI/IRI work without a normative reference
to RFC 3987.  However, 3987 is obsolete, not in the sense of
formal IETF action, but because the action has shifted to W3C.
It is not clear that the state of the work there would meet IETF
requirements for normative references from standards-track
specs.  Simply sorting that out could take months.  Absent clear
requirements anchored in real needs to deal with the problem of
URNs containing non-ASCII characters in non-encoded form (ACE,
%, or otherwise), I don't think the delay is acceptable.

Now the ASCII non-LDH characters are another matter, but we have
applied that restriction to more flavors of identifier than I
know how to count, including notably (and as mentioned above and
below) the NID itself.  If there is an important case to be made
for allowing a wider range of syntax in the resolverID than in
the NID, I don't think you have made it yet (arguing for
non-ASCII names is another matter, but most of those arguments
would also apply to the NID).  

Otherwise, I'd recommend that we just move on or, if specifying
a resolverID requires resolving (sic) this and it is actually
controversial in the WG, pulling that syntax distinction out of
r-component and leaving it all for future standardization.

> Keep it expansive. If you want you can add a note to the
> effect of, "resolverID is supposed to be limited to LDH, other
> characters are RESERVED or may have RESERVED purposes in other
> specifications." (I do not advocate for this position, but I
> am pointing out how to do it correctly, rather than put the
> limit in the ABNF. Note that is how RFC 2141 dealt with the
> issue of characters such as "?" and "#".)

See above.  Also note that the way RFC 2141 dealt with those
characters caused us months of debate about whether URNs could
be extended at all and about whether there were non-conforming
cases (in which those characters had been used in some way) for
which we needed to make allowances.

>>> ...
>>> Since we are defining resolverID, the momentum is sufficient
>>> to structure the syntax of the other part. Although I am not
>>> combing through the history of the mailing list, I believe a
>>> handful of voices called for name/value pairs, and nobody
>>> strenuously objected.
>> Again, I believe the WG explicitly decided to not do this,
> 
> My recollection is that there were calls for the structure of
> name/value pairs that got a lot of serious consideration. If
> we can agree on name/value pairs then we will make serious
> technical progress.

Having first introduced the idea of structuring things around,
and requiring, name-value pairs (before the q-component/
r-component separation), I just can't recommend going there, or
otherwise trying to structure the syntax of the string, at this
stage.  I still think name-value pairs would be a good idea for
r-component (even if not for q-component) but I just don't see
enough energy in the WG to work through the details, decide what
needs to be registered and how, sort out permitted characters,
etc.   At this point, I think the most we can sensibly do is to
be sure that reasonable and plausible name-value constructions
are not forbidden.  

What you see as "serious technical progress" is what I see as an
opportunity to fuss for months on an issue that is not in the
WG's critical path and for which we have little actual
experience.  Those two views can be held at the same time --
i.e., they are not inherently contradictory -- but I believe the
WG's marching orders are to get finished with 2141bis and the
documents closely linked to it and to avoid being distracted by
issues that are not absolutely necessary to it.

In case it isn't clear, that is an expression of agreement with
Peter's and Leslie's conclusion in
https://mailarchive.ietf.org/arch/msg/urn/78hKQSNHvlBx1RJnPUOczkykkFs
-- this needs to be considered far out of scope if we are going
to get finished.

> The discussion faltered on a *registry* of r-component
> name/value pairs, but that was about reserving specific names,
> not about the syntactic structure.

But Keith's note at
https://mailarchive.ietf.org/arch/msg/urn/cOq7rl_zd4pCPdZ-kpLm-ujBvoM
suggests that we need "name" as well as "name=value".   Again, I
don't necessarily disagree, just see a need to route the WG's
critical path around this, at least if we would like to finish
2141bis any time soon.

     john

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 22 Mar 2016 18:41:47 +0900

> sequences are used inside the component strings.

I don't think there is a need for multiple levels of %-encoding. There 
are only two levels:

a) payload (which includes any component-internal stuff such as 
query/resolver parameter names and values,...)
b) syntactic delimiters

Essentially, anything that looks like b) but is in a) has to be escaped, 
exactly once. That includes '%'. Whether that's part of domain name 
(just for the sake of the argument assuming that's possible), part of a 
path name, part of a NID, part of a namespace-specific string, part of a 
q-component or an r-component or of anything else, just escape it once, 
and things should work fine.

Regards,   Martin.

---

From: John C Klensin <[email-masked]>
Date: Tue, 22 Mar 2016 10:48:48 -0400

--On Tuesday, March 22, 2016 18:41 +0900 "Martin J. Dürst"
<[email-masked]> wrote:

> I don't think there is a need for multiple levels of
> %-encoding. There are only two levels:
> 
> a) payload (which includes any component-internal stuff such
> as query/resolver parameter names and values,...)
> b) syntactic delimiters
> 
> Essentially, anything that looks like b) but is in a) has to
> be escaped, exactly once. That includes '%'. Whether that's
> part of domain name (just for the sake of the argument
> assuming that's possible), part of a path name, part of a NID,
> part of a namespace-specific string, part of a q-component or
> an r-component or of anything else, just escape it once, and
> things should work fine.

In case it was not clear from my attempt to reason through the
situation, I completely agree (and would accept your judgment
even if I had not agreed earlier.

thanks for reading the stuff and replying.

     john

p.s. The "part of a domain name" issue is an example of why we
need to be very careful about what questions are being asked and
to be sure the answers are interpreted in the light of those
questions.  As far as the DNS is concerned, it is possible to
put any octet, including the oft-problematic X'00' and X'FF',
spaces, and periods, in a domain name label.  However most
applications (including anything following 3986) will get
thoroughly annoyed by anything outside the ASCII range (i.e.,
high bit 'on') and almost as many will be annoyed by anything
that does not conform to the so-called LDH rule (i.e., what the
basic DNS specs call the "preferred syntax").    I know you,
Martin, know that, but, in case anyone was confused...

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Mar 2016 21:13:59 -0600

On 2/21/16 10:21 PM, Martin J. Dürst wrote:
> On 2016/02/22 06:04, Sean Leonard wrote:
>> On 2/21/2016 12:24 PM, John C Klensin wrote:
>
> Sean wrote:
>>>>   From that view, it follows that r-component is
>>>> namespace-independent, in the sense that the maintainers of
>>>> urn:isbn, urn:oid, urn:ietf, urn:nbn, etc. do not each get a
>>>> stab at their own spins on the resolverID "foo" or "info" or
>>>> "abcdefg". The namespaces of "resolverID" and therefore
>>>> r-components more generally are global and orthogonal to the
>>>> NID / NSS part.
>>> I hope that is consistent with what the text says.  However, the
>>> intent of the text was that maintainers of particular namespaces
>>> _do_ get to specify what resolverIDs are used with them, just
>>> not how a given resolverID that they intend to permit is
>>> interpreted.
>>
>> I am confused with these two statements/positions and do not see how to
>> separate them.
>>
>> I think an example from you would be very helpful.
>
> I think I understand what John is trying to say: If there's a resolverID
> "info", and that's (for simplicity's sake) defined to return info about
> the author(s) and the length of the document in bytes, then it's not
> possible for a namespace maintainer to say that for the particular
> namespace, the "info" resolver also returns the date of creation, or
> doesn't return the length in bytes, and so on. In other words, opt-in
> for each resolverID is binary.
>
> That still leaves us with the problem below.
>
>> As you wrote: "maintainers of particular namespaces [get] to specify
>> what resolverIDs are used with them". And: namespace maintainers do not
>> get to specify "how a given resolverID that they intend to permit is
>> interpreted".
>>
>> So the maintainer of urn:isbn can say the resolverID "info" can be used,
>> and "get" cannot be used. The maintainer of urn:oid can say the
>> resolverID "info" can be used, and "get" can also be used.
>>
>> But why do they say some resolverIDs can be used or not, when they have
>> no way to promulgate what it means?
>>
>> It is like saying: "You can use the number 6 in this protocol, but not
>> the number 7. Oh, but you can do whatever you want when you receive a 6."
>>
>> Usually the party that specifies the values, also specifies the meanings
>> of the values.
>>
>>
>> I actually do not care whether the resolverID is namespace-dependent or
>> namespace-independent. As I have pointed out, a resolver receives both
>> the resolverID and the NID (plus the NSS, of course), so at the level of
>> resolver behavior, the behavior will always be namespace-dependent
>> because it depends on the identity of the thing being named.
>>
>> Right now the specification equivocates because sometimes it says
>> independent and sometimes it says dependent. That is a problem.
>>
>> Upon reasoning it through, my position was:
>>
>> "people writing durable, universal naming
>> schemes should not be required to be in the business
>> (directly) of dictating what resolution services get developed
>> or not, and vice-versa. I.e., the URN namespace registration
>> template should not require new URN namespaces to specify a
>> set of resolution ops."
>>
>>
>> This is based on making it easier to register URNs. If resolverIDs
>> (resolver operations) are namespace-dependent, we must expect the URN
>> registration template to define resolution a lot better. That is more
>> work. And it may change over time based on different parties' needs.
>
> I guess I'm with Sean here. Sean maybe implied this, but I didn't see it
> stated explicitly: It would make introduction of new resolution services
> (which might perfectly well be able to deal with preexisting URN
> namespaces) a lot more difficult. We don't have any magic to update
> specs or registrations automatically.
>
> So at the most, I'd want to limit us to something like "Namespace
> registrations MAY indicate some of the types of resolvers suitable for
> the namespace (by listing the relevant resolverIDs). Such a list does
> not restrict the use of resolvers to only the listed types."

That seems reasonable to me.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Mar 2016 21:20:13 -0600

> 3986 and the two-character starting and ending delimiters.

To state it explicitly: I agree with John here.

Peter

---

From: Sean Leonard <[email-masked]>
Date: Tue, 22 Mar 2016 23:01:47 -0700

> That seems reasonable to me.

I can live with text like what Martin proposed. (With the proposed text 
being the high-water mark. I.e., namespace registrations may indicate 
some of the types of suitable resolvers...but they don't have to...and 
actually if they don't it's okay too...and since it's more text, why 
burden the namespace registrant with writing much of anything about that 
in the first place...)

Sean

PS There was a huge burst of urn e-mail going back and forth (mostly 
forth) recently...I intend to reply...but it will take a few days to 
digest...and quite possibly want to pop up a level and figure out where 
we have come and how we can get to wherever we're trying to go...

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Mar 2016 03:56:02 -0400

>> So at the most, I'd want to limit us to something like
>> "Namespace registrations MAY indicate some of the types of
>> resolvers suitable for the namespace (by listing the relevant
>> resolverIDs). Such a list does not restrict the use of
>> resolvers to only the listed types."
> 

<editor hat="on">

Putting this in context with other discussions and trying to
retrofit it into the document, if we were to tear the resolverID
stuff out (a decision I don't think has been made yet), the
above would replace the second paragraph of Section 6.4.6
(2141bis-15), which starts:

	"If resolution is intended, then this section SHOULD
	specify whether the organization that assigns URNs
	within the namespace intends to operate or recommend any
	resolution services for URNs within that namespace...") 
	
with the above, with the parenthetical comment removed.  

That takes us to considerably less specificity than RFF 3406,
whose Section 4.3 describes differences in resolution/delegation
as part of the justification for creating/registering new URNs.
More important, the "Namespace Definition Template" in Appendix
A of 3406 has a rather specific requirement in a subsection that
begins:

   "Process for identifier resolution:

	If a namespace is intended to be accessible for global
	resolution, it must be registered in an RDS (Resolution
	Discovery System, see [RFC2276]) such as DDDS.  Resolution
	then proceeds according to standard URI resolution
	processes, and the mechanisms of the RDS.  What this
	section should outline is the requirements for becoming a
	recognized resolver of URNs in this namespace (and being
	so- listed in the RDS registry)."

Now, that came out because we dropped the RDS (and DDDS)
discussions. I assume that Peter or I (can't remember who) wrote
the new text to preserve something of the same "if the URN is
expected to resolve, you must provide some hint of where and how
to find an appropriate resolver" favor of the 3406 requirement.
Martin's suggested text above means, I think, that either:

	-- A new registration of a URN that is expected to be
	resolved MAY provide no information about resolution or
	resolution services for that namespace at all    

or that

	-- An r-component is effectively required for any URN
	that is to be resolved.

We cannot intend the second if we are intending to leave
r-components for future standardization because it would result
in a considerable loss of functionality compared to the
2141/3406 combination.  It would also get us into a silly state
wrt some of the material in the Introduction and elsewhere in
2141bis.

I'm ok with the first interpretation and can try to make up (or
accept from someone else) some wording elsewhere in the document
that would make having a resolvable URN with no information
about resolution mechanisms or services (even a disclaimer that
punts the problem elsewhere) ok, but it seems drastic enough
that I wanted to check that is what the WG (and even Martin and
Peter) intend.  

If not, I need advice or instructions as to how to put Martin's
paragraph in and where.

</editor>
<editor hat-off>

That paragraph seemed like a really good idea to me until I
started looking at the text.

</editor>
<editor hat=on>
In the process of looking at the document for the above, I
discovered that the third paragraph of Section 2.3 of 2141bis-15
("Whenever a URN resolves to a URL...") says:

	"The semantics of q-component and f-component for URNs
	that inherently cannot be resolved to a URL (i.e., for
	abstract designators) are undefined..."
	
I believe the "i.e." is a typographical error and should be
"e.g.".  Otherwise, the sentence effectives requires all URNs
that can be resolved to resolve to URLs.  I think discussions
have been clear that we do not intend that restriction.   I'm
planning to correct it unless someone believe that wording was
intended (and either the restriction is too or there is some
other interpretation for what the sentence says).

</editor>

<whine (and warning)>

One of the accidental advantages of the pen passing back and
forth every couple of revisions between Peter and myself is that
the odds of little things like the above getting caught and
fixed go up.  But the document is ultimately the WG's
responsibility and publishing it with that sort of error would
be bad news, probably requiring issuing a revised document if
anyone felt the change was substantive.  So please read the
thing and read it carefully.
</whine>

   john

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 24 Mar 2016 13:37:46 +0900

[Comments further down.]

> 	resolution services for that namespace at all

That was my intent, although in a spec, I'd write it positively:

A new registration of a URN that is expected to be
resolved MAY provide some information about resolution or
resolution services for that namespace

> 2141/3406 combination.

Not only that, it would also mean that all currently URNs currently 
existing in the wild are unresolvable without further tweaking, which 
hopefully nobody would want. As far as I understand the intention behind 
r-components, their primary purpose is to be able to indicate resolution 
details if necessary, not to be a prerequisite for resolution. Also, it 
would heavily disadvantage URNs vs. URLs, which in most cases "just work".

> that I wanted to check that is what the WG (and even Martin and

Ah, I see, you (and maybe the WG) are afraid that without any 
explanations on how URNs in a namespace might actually get resolved, 
there's not much of resolvability left. That's a valid concern.

I didn't consider that when I wrote the proposed text that's now at the 
start of this mail, because then I was just concerned with the wording 
about resolver types (which were connected to resolver IDs).

If we are scaling down the text on resolvers and leave r-component 
details as "future work", then resolver IDs are no longer relevant. The 
text would then be meant in a much more generic fashion, i.e. "resolver 
types" being just a generic term, rather than something well-defined.

But dropping the whole paragraph would also be fine.

Regards,    Martin.

---

From: John C Klensin <[email-masked]>
Date: Thu, 24 Mar 2016 12:59:56 -0400

--On Thursday, March 24, 2016 13:37 +0900 "Martin J. Dürst"
<[email-masked]> wrote:

>> I'm ok with the first interpretation and can try to make up
>> (or accept from someone else) some wording elsewhere in the
>> document that would make having a resolvable URN with no
>> information about resolution mechanisms or services (even a
>> disclaimer that punts the problem elsewhere) ok, but it seems
>> drastic enough that I wanted to check that is what the WG
>> (and even Martin and Peter) intend.
> 
> explanations on how URNs in a namespace might actually get
> resolved, there's not much of resolvability left. That's a
> valid concern.

Yes. That is the issue.  Right now, if a URN is resolvable, we
have a requirement that the registration say something specific
about the mechanism to be used or how to find it.  

> I didn't consider that when I wrote the proposed text that's
> now at the start of this mail, because then I was just
> concerned with the wording about resolver types (which were
> connected to resolver IDs).

Right.  As I tried to say, my initial reaction was the same and
I was very happy with your text.  It was only after I tried to
insert it into the document that I realized there was a problem.

> If we are scaling down the text on resolvers and leave
> r-component details as "future work", then resolver IDs are no
> longer relevant. The text would then be meant in a much more
> generic fashion, i.e. "resolver types" being just a generic
> term, rather than something well-defined.
> 

Let's see if anyone else wants to comment... then I'll try to
make a specific proposal.  Of course, if all discussion of
r-component is removed other than "future standardization", this
particular part becomes easy because the existing text probably
works.

thanks,
    john