Subject: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review

From: John C Klensin <[email-masked]>
Date: Wed, 01 Apr 2015 15:33:18 -0400

Hi.

I've been thinking more about Larry's claim [1] that
draft-ietf-appsawg-uri-scheme-reg (referred to as "4395bis"
below) constrains work going on in the URNBIS WG and, in
particular, draft-ietf-urnbis-rfc2141bis-urn and have been
studying both documents.

This is not a late review in the usual sense.  Under normal
circumstances, I would consider a WG document to update a
registration model to be routine and in good hands and reached
precisely that conclusion about this specification after
glancing through an early version.  What has changed is the
assertion that this document constrains the work of the URNBIS
WG and actually invalidates decisions already made there.  If
true, that raises significant issues of a variety that, had they
arisen after IESG approval, would properly have resulted in
appeals.   I think we should consider it fortunate that the
issue has arisen before things reached IESG balloting.

Some of Larry's comments involve substantive issues about URNs
or decisions made in, or under consideration by, the URNBIS WG.
I assume that they will be taken up in an ordinary way on that
WG's list (a response from me to some of them can be expected
soon although it seemed important to get these notes out first).
However, the interactions between 4395bis and the URN work raise
some fundamental questions about 4395bis that I hope can be
resolved without either holding it up significantly or dropping
it into a procedural quagmire. 

We have a situation in which two WGs (notably two WGs that are
responsible to the same AD) are aware of each other's work and
claims are made that the work conflicts or that one effort
dominates the other.   Certainly both the principles of openness
and fairness that are called out repeatedly in RFC 2026 and our
long-term practices suggest that the relevant documents should
be considered at the same time and, as appropriate, be reviewed
and achieve at least rough consensus in both WGs unless the
conflicts can be eliminated in other ways.   In particular,
neither WG (or document authors) should be able to establish
their document as controlling the other by creating a race
condition.

In this case, the following specific issues seem relevant to
resolving, eliminating, or clarifying the claimed conflict about
controlling text.

(1) I note that there has been a title change between RFC 4395
("Guidelines and Registration Procedures for New URI Schemes")
and 4395bis ("Guidelines and Registration Procedures for URI
Schemes") that the authors of the latter did not consider
significant enough to note in their discussion of changes in
Appendix A.

The third paragraph of Section 1 begins "This document provides
updated guidelines for the definition of new schemes..." and
"new" is repeated at the beginning of Section 3 and at several
other points in the document.  I infer from that, as well as the
above, that the change of title is not intended to be
substantive and that, in particular, the procedures established
or updated by this document do not alter or constrain any of 

 (i) Procedures for updating established registrations
	
 (ii) The ability for a new registration to specify
	appropriate updating procedures for that scheme
	definition
	
 (iii) The ability for the authoritative entity for a
	particular already-registered scheme to change the rules
	for updating that scheme.  When that scheme definition
	is part of an IETF standards-track document, the usual
	rules for updating standards-track documents apply.
	
and that,
 (iv) As (probably) pointed out at the end of the second
	paragraph of the introduction, URN namespaces are not
	part of the scope of this document.

As I read 4395bis, all of those statements seem clear to me.
However, if Larry, especially in his capacity as a listed
co-author of 4395bis, reads it in a different way, I think some
clarification is probably necessary (and that, if there is no
agreement that these are really clarifications, that the
document should be returned to the WG):

 Clarification #1: Either restore "new" to the title and
	add it to the Abstract or insert an explicit statement
	in the Introduction that reflects the above, ideally all
	three.
	
 Clarification #2: Either clarify very precisely what
	"explicitly" means in the sentence  'URN "namespaces"
	([RFC3406]) are specific to the "urn" scheme and are not
	covered explicitly by this specification.' (a sentence
	4395bis appears to have incorporated without change from
	4395) or drop "explicitly" from that sentence.

(2) Section 3 of 4395bis cites the "overall syntax for URIs"
from RFC 3986 and then says 

	"A scheme definition cannot override the overall syntax
	for URIs.  For example, this means that fragment
	identifiers cannot be re-used outside the generic syntax
	restrictions, and fragment identifiers are not
	scheme-specific."

If we can agree that this is not applicable to existing
registered scheme definitions or updates to them and that future
URN-like schemes are unlikely, then that is a non-issue.  If we
cannot, the AppsAWG and IESG should be formally aware (the
former has certainly been told about this in various area
meetings) that the current consensus within URNBIS is to
separate URNs from the semantic requirements of 3986 [2].  That
position was the result of a difficult compromise in which the
main alternative was to separate URNs entirely from what the WG
believes are the many assumptions (most derived from locators)
and some of the confusing language in 3986.

The paragraph quoted above appears to be new to 4395bis, does
not appear to be noted in the appendix that lists changes, and I
wonder why it was felt to be necessary.  Whether it is
applicable to the "urn" scheme or not, the statement is
factually false.  The only constraint the "overall syntax for
URIs" imposes on what 3986 calls a "fragment" is that it be
preceded by "#", that it extend to the end of the URI, and that
it obey the usual rules about permitted characters and character
escaping.   Statements about fragment identifiers being
scheme-specific are _semantic_ restrictions and, absent a good
deal of semantics, I can't even figure out what "fragment
identifiers cannot be re-used outside the generic syntax
restrictions" might mean.

 Clarification #3: Either explicitly exempt URNs (either
	by name or by "not applicable to existing
	registrations") or fix that paragraph to clarify the
	difference between syntax and semantic restrictions.  In
	the interest of correctness and technical accuracy, a
	fix seems preferable to an exemption.  The thing I think
	we should avoid (even though it would be easy from a
	textual standpoint) is having to put text in the URNBIS
	documents that updates 4395bis to remove this particular
	apparent requirement.   If we have to have a battle over
	the applicability of that text, it seems to me that the 
   time to do it is while both documents are still under
	consideration, i.e., now.

(3) I observe that 4395bis appears to considerably increase and
tighten the binding to 3986 relative to 4395, with the above
being just one example.  Those who have been watching
developments closely are aware that there are multiple efforts
in progress in different organizations that have the intent to
revise or even supercede 3986.  The IETF has not taken a strong
position about those other efforts and there have apparently
been AD-level discussions about ceding generic URI work to other
bodies.   Given that state of uncertainty and the IETF's
presumed desire to avoid having changes in the status of 3986
drag this 4395bis specification into obsolescence, it would seem
desirable to make this document and procedure less, rather than
more, dependent on specific text and wording in 3986.
Alternately, if the intent of those additional dependencies is
to try to defend against internal or external alterations to
3986, I believe that should be handled up front rather than
trying to use this registration specification as a back door.

 Clarification #4/ Recommendation: The authors or others
	should make a careful pass through this document,
	eliminating specific dependencies on 3986 where possible
	and clarifying the intent of what remains sufficiently
	to preserve the effectiveness of this specification
	should 3986 be superceded.   If that is not feasible,
	the IANA Considerations section of this document should
	be clear about the status of the registration procedure
	(and the registry that it specifies) should the
	references on which the spec is normatively dependent be
	superceded (that would probably be a good idea for all
	registration specifications that are not self-contained,
	but it is important in this case because there appears
	to be a real possibility that documents that supercede
	3986 will not be under IETF change control).

(4) The second sentence of the first paragraph of Section 3.3
("Well-defined") says:

	"Schemes that are not intended to be used as locators
	SHOULD describe how the resource identified can be
	determined or accessed by software that obtains a URI of
	that scheme."

If this is intended to be applicable to URN or URN-like schemes
that are used as what URNBIS has been calling "indicators", it
is not clear what the requirement statement means.  Requirement
statements without clean meaning vis-a-vis all of the cases to
which they might apply are undesirable and are indeed "technical
deficiencies".

 Clarification #5: Either clarify the excluded cases
	implied by the "SHOULD" or explicitly exempt URNs and
	any similar schemes that might be developed or
	registered in the future.

(5)  The last paragraph of Section 3.3, much of it copied intact
from RFC 4395, suggests a requirement that all "legal protocol
interactions" of another protocol must be capable of being
mapped into the URI and calls out "ftp" as an example.  One
significant change from 4395 (not noted in the Appendix that
lists changes) is the transformation from an informal "must"
suggestion about the mapping model to a normative "MUST".  That
"MUST" actually contradicts the final sentence of the paragraph
which begins "If not all legal values or protocol interactions
of the base standard can be represented..."

This raises two issues.  First, if 4395bis (especially its
normative requirements) is to be applied retroactively to
existing registrations, then the registration of the ftp scheme
is now invalid (whether that last sentence is considered as a
path to an exception or not).  First, the discussion in RFC
1738, which is referenced as the definition of the scheme from
the IANA registry, is not complete relative to the functionality
of the FTP protocol as of the time RFC 1738 was written and does
not explain the exceptions.  It even says that it is incomplete
with the rather magical sentence (in Section 3.2.2 of RFC 1738)
that reads "The mechanism for doing so is not spelled out here."
The IETF has also chosen to standardize a number of extensions
to FTP (including, in these IPv6 and security-conscious days,
RFCs 2428 and 4217) that have not been reflected in either the
registration or in an update to RFC 1738.  Second, even for new
registrations, changing informal guidance that happens to use
the word "must" to a normative absolute requirement (with
"MUST") should require much more careful review and evaluation
by the community than this change appears to have gotten
(especially given the apparent contradiction it introduces).

FWIW, I haven't done a careful review, but it is not clear to me
that even the "http:" scheme, as reflected in the IANA registry,
would be considered valid by the criteria in 4395bis given
functionality changes introduced by HTTP2 and other relatively
recent changes and extensions.

I note, also FWIW, that Section 3.4 is much more balanced and
reasoned and that it uses "SHOULD" consistently and not "MUST".

Retroactive application of Section 3.7 ("Clear Security
Considerations") would also invalidate a number of existing
registrations.

 Clarification #6: This example, which has nothing to do
	with URNs or, unless the long-expired
	draft-hoffman-ftp-uri is considered, any other active
	URI-defining work in the IETF, points out another reason
	why it is important that this 4395bis document
	explicitly disclaim applicability to any
	already-registered scheme or updates to it except as the
	most general guidance and recommendations of issues to 
   be considered.
	
 Clarification #7: The MUST in the cited paragraph should
	be, at most, a "SHOULD" or the paragraph should be
	reworded to correctly reflect realistic intent.

 Clarification #8/Recommendation: The list of Changes in
	Appendix A should be expanded to reflect all changes
	from general guidance (expressed in, e.g., "must" or
	"should") to normative requirements.  Treating such
	changes as editorial corrections is appropriate only
	when the context clearly indicates normative intent and
	the changes do not introduce contradictions either
	within the text or to established practices.

(6) URN work has made it clear that defining the scope of
applicability of a URI scheme is, at best, a shared
responsibility between whatever documentation defines the scheme
and the documentation that defines the referencing context.
Attempts to shift all of that responsibility to the scheme
definition, as Section 3.5 can be interpreted to do, is
unrealistic if only because the scheme definition cannot predict
referencing contexts that might be defined or redefined in the
future.  Given that the current text uses a "SHOULD", it is
probably ok, but a clarification that contexts that incorporate
URI references also bear some responsibility for describing the
schemes that are valid and meaningful (preferably on an
inclusion basis) would be helpful to avoid outrageous claims in
the future.  Anyone contemplating a 4395ter might consider
whether adding an "applicable application, protocol, or context"
field to the IANA registry would be useful.

 Clarification #9: Add a sentence to Section 3.5 to
	clarify that its provisions do not eliminate the
	requirement for the applications and/or protocols from
	which URIs are used to discuss the schemes that are (or
	are not) relevant and appropriate for use in those
	contexts.

(7) In my capacity as someone who is supposed to know a bit
about i18n issues, I think I understand the intent that
motivated the inclusion of the last paragraph of Section 3.6.
However, after reading that paragraph several times, I am not
sure what it actually means.  If the term "variant" (which I
would encourage authors to avoid) is interpreted in its ICANN
usage or even as defined in Section 7.2 of RFC 6365, I am _sure_
I don't know what the paragraph means.

 Clarification #10: That paragraph needs to be rewritten
	and carefully checked by i18n experts.  Encouraging the
	registration to make a clear statement about
	normalization and/or other comparison-related issues
	would probably be desirable.

(8) Section 7.3 is not explicit that an updated registration can
change the mechanism for future updates, nor that registrations,
especially those associated with IETF documents, can specify
update/change mechanisms different from those specified in this
document.   Had I been asked a month ago, I would have said that
both were obvious and that further explanation was not required.
Since recent discussions have called both into question, I think
some clarification is needed.

 Clarification #11: Add text to Section 7.3 to make it
	explicit that scheme registrations MAY specify updating
	procedures that are more specific than those outlined in
	4395bis, including identifying other approval mechanisms
	or responsible parties, and that scheme registration
	updates may modify the updating mechanism as well as
	other aspects of the registration.

 Clarification #12: In the template shown in Section 7.4,
	add to the "Change controller:" entry a statement
	equivalent to "Any special considerations about updating
	or updating procedures should also appear as part of
	this item."

(9) Further evidence that this document is confused about
existing registrations, retroactive application, and its own
requirements appears in Section 8.   The "example" URI scheme
registration that is specified in that section does not appear
to conform to the "fields that MUST be supplied" requirements of
Section 7.4: there is no contact given and the "Change
controller" field is identified as "Author/Change controller".
If that flexibility was intended by Section 7.4, the document
should say so.

thanks,
    john

[1]
http://www.ietf.org/mail-archive/web/urn/current/msg02873.html

[2]
https://datatracker.ietf.org/doc/draft-ietf-urnbis-semantics-clarif/

---

From: Graham Klyne <[email-masked]>
Date: Thu, 02 Apr 2015 10:43:03 +0100

> and some of the confusing language in 3986.

Procedural matters aside, I think this is an important clarification, and that 
urn: URIs SHOULD be constrained by this.  This is not about existing and new URI 
schemes, but about what is required to be a a valid URI.

My reason is that there is software out there that is written to accept 
*anything* that is a valid URI, and legitimately expect such strings to confirm 
to RFC3986 syntax (not withstanding Sam Ruby's efforts to document variations 
between systems about what they accept as a valid URI).  If URNs are to be 
usable as URIs in such circumstances, I think it's important that they follow 
the rules, including those concerning the role of fragment identifiers.

Procedurally, the URN working group might decide that URNs are not URIs, and 
hence be released from adhering to URI constraints, but that would be most 
unfortunate in that a possibly-important class of identifiers would be excluded 
from use by an important class of applications.

#g
--

> scheme-specific are_semantic_  restrictions and, absent a good

---

From: Graham Klyne <[email-masked]>
Date: Thu, 02 Apr 2015 10:43:03 +0100

#g
--

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Apr 2015 09:08:28 -0400

Just to one point:

> *anything* that is a valid URI, and legitimately expect such strings to
> confirm to RFC3986 syntax (not withstanding Sam Ruby's efforts to document
> variations between systems about what they accept as a valid URI).

Absolutely.  And the URNbis document maintains that, but keeping URNs
syntactically URIs.

> If URNs
> are to be usable as URIs in such circumstances, I think it's important that
> they follow the rules, including those concerning the role of fragment
> identifiers.

Here's where I don't agree.  If URN fragments (f-components, or
friggle-fraggles... the bit after the "#") are semantically somewhat
different to what 3986 says about fragments in locators, because
that's what semantically makes sense for URNs, why does that stop
anyone from continuing to use them in places where URIs are
syntactically required?

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Apr 2015 09:08:28 -0400

Barry

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Apr 2015 10:19:02 -0400

Barry has commented on the more important part of this, but an
observation on the other part...

--On Thursday, April 02, 2015 10:43 +0100 Graham Klyne
<[email-masked]> wrote:

>> registered scheme definitions or updates to them and that
>> future URN-like schemes are unlikely, then that is a
>> non-issue.  If we cannot, the AppsAWG and IESG should be
>> formally aware (the former has certainly been told about this
>> in various area meetings) that the current consensus within
>> URNBIS is to separate URNs from the semantic requirements of
>> 3986 [2].  That position was the result of a difficult
>> compromise in which the main alternative was to separate URNs
>> entirely from what the WG believes are the many assumptions
>> (most derived from locators) and some of the confusing
>> language in 3986.
> 
> Procedural matters aside, I think this is an important
> clarification, and that urn: URIs SHOULD be constrained by
> this.  This is not about existing and new URI schemes, but
> about what is required to be a a valid URI.

Procedural issues very much not aside, I would like to see if we
can navigate the very large collection of URI issues (including
those being discussed outside IETF) in a way that doesn't make
everything so dependent on everything else that we cannot move
any document (including this one) forward without moving
everything else forward at the same time.

If, as you suggest, language in
draft-ietf-appsawg-uri-scheme-reg-05 "clarifies" what is
required to be a valid URI, especially in a way that affects
both existing and future ones, then it necessarily updates 3986.
If it does that, then it is missing the required "Updates"
indication (trivial) and the required explanation of what parts
or provisions of 3986 are being updated and how.  So, if you
believe the above, you have just made a significant procedural
objection to processing the draft in its current form.   While
that might be a minor issue for some documents, easily corrected
by an RFC Editor note, I believe there is ample reason to
believe that a description of what is being updated and why
would turn out to be controversial and difficult in terms of
achieving consensus.

At least from my perspective, the problem goes beyond that and
into issues I have identified earlier.  If
draft-ietf-appsawg-uri-scheme-reg modifies what it is possible
to do in ongoing URN work beyond whatever is clearly specified
in 3986, then any of the active participants in URNBIS (or those
concerned about its output, whether actively participating or
not) are entitled to raise the issue of whether openness and
fairness allows draft-ietf-appsawg-uri-scheme-reg to be
processed independently of the URN documents that it claims to
restrict.   Equally frighteningly, if
draft-ietf-appsawg-uri-scheme-reg changes the fundamental
validity criteria for URIs as specified (or claimed to be
specified) in 3986, it presumably [re]opens all of the issues
about what 3986 actually requires rather than recommending or
discussing and probably requires reaching consensus on and
documenting such topics as those raised in the rather extensive
threads about 3986 validity and scope that showed up in January
and not moving _any_ of these documents forward until 3986bis
(the right place to apply such clarifications) is ready for IETF
Last Call.

Another complication is that if there is disagreement in the
community about the scope of draft-ietf-appsawg-uri-scheme-reg
before it is even approved, you are a partisan for one position
in that matter and that combination might cause reasonable
people to be concerned about perceptions of possible
interactions between those issues and your role as Designated
Expert.  

I hope we can avoid going into a place where all of these issues
become procedurally interlocked but when some of the authors and
a subset of the (I believe few) people who carefully reviewed
draft-ietf-appsawg-uri-scheme-reg disagree on its scope and
applicability, we are not in good shape for avoiding that
outcome.

    john

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Apr 2015 10:19:02 -0400

john

---

From: Graham Klyne <[email-masked]>
Date: Sat, 04 Apr 2015 15:40:44 +0100

> Absolutely.  And the URNbis document maintains that, but keeping URNs

Yes, and as long as URNs are used simply as strings meeting certain syntactic 
constraints, there's no problem...

> anyone from continuing to use them in places where URIs are

The problems potentially arise when a URI is used for dereferencing.  The Web 
architecture is quite clear that the fragment is not used when dereferencing a 
resource on the web (http://www.w3.org/TR/webarch/#media-type-fragid).  (I 
assert that URIs are, first and foremost, a central protocol element of the Web, 
and anything that claims to be a URI should conform to Web architecture principles.)

To the case in point, if URNs are ever to be used for dereferencing (in the 
Web), then it is important that the fragment identifier may be stripped at this 
point, as that is how URI-dereferencing software may be written.  (You might say 
that URNs are not used for dereferencing.  I say never say never - e.g. consider 
the IETF spec for DDDS (https://tools.ietf.org/html/rfc3402)).

In summary, if URNs adopt fragment syntax as a part of the primary resource 
identifier (as opposed to a secondary resource in the sense indicated by web 
architecture - http://www.w3.org/TR/webarch/#fragid), then I think there's a 
risk that they may become unusable on the Web in some situations where URIs are 
used.  They would not be URIs.

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Sat, 04 Apr 2015 15:40:44 +0100

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Sat, 04 Apr 2015 16:02:24 +0100

Barry,

(backtracking on my previous response...)

I just realized my last response to you wasn't right.  I argued that the 
fragment should not be part of a primary resource identifier.  On reflection, I 
think that's wrong - there are already examples of URIs with fragment 
identifiers used as (primary) resource identifiers.  (E.g. they are commonly so 
used in RDF.)

They key point, I think, is that the identifier including fragment cannot be 
used directly to retrieve a representation of the identified resource on the Web.

So if a URN does use a fragment as part of an identifier (other than by 
"indirect identification of a secondary resource by reference to a primary 
resource" [http://tools.ietf.org/html/rfc3986#section-3.5]), then that form of 
URN cannot be used directly for Web dereferencing of the identified resource. 
But it could be mapped by a particular access protocol to some other URI that 
can be so used (e.g. using DDDS).

I therefore soften my previous stance about the role of fragment identifiers in 
URNs, but I would tend to recommend against using them unless the fragment-less 
identifier can be understood as identifying some appropriate "gateway" resource.

However, there is another aspect of fragment identifiers as defined by RFC3986 
that is purely syntactic - they are part of the hierarchy that comes into play 
when resolving a URI reference against some base URI, and I still think that 
aspect should be respected by URNs.

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Sat, 04 Apr 2015 16:02:24 +0100

Barry,

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Sat, 04 Apr 2015 16:05:04 +0100

> both existing and future ones, then it necessarily updates 3986.

I certainly did not mean to suggest that.

I think that draft-ietf-appsawg-uri-scheme-reg-05 has no place "clarifying" what 
it is to be a URI - that is the role of RFC3986.  I did not think it does this, 
but if you think it does, I would be interested to understand where and why.

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Sat, 04 Apr 2015 16:05:04 +0100

#g
--

---

From: Dave Thaler <[email-masked]>
Date: Wed, 8 Apr 2015 01:05:41 +0000

John Klensin wrote:
> (1) I note that there has been a title change between RFC 4395 ("Guidelines
> and Registration Procedures for New URI Schemes") and 4395bis ("Guidelines
> and Registration Procedures for URI
> Schemes") that the authors of the latter did not consider significant enough
> to note in their discussion of changes in Appendix A.

Correct, because RFC 4395 already covered guidelines and procedures for
updating existing schemes as well as registering new schemes.  The word "New"
in the title of the original RFC simply did not match the actual content.

> The third paragraph of Section 1 begins "This document provides updated
> guidelines for the definition of new schemes..." and "new" is repeated at the
> beginning of Section 3 and at several other points in the document.  I infer
> from that, as well as the above, that the change of title is not intended to be
> substantive 

Correct as noted above.

> and that, in particular, the procedures established or updated by
> this document do not alter or constrain any of

Not quite correct.  The statement in section 1 and section 3 are about new schemes.
*Other* sections of the document (section 7.3 in particular, which replaces
Section 5.3 of RFC 4395) update the process for updating established registrations.
 
>  (ii) The ability for a new registration to specify appropriate updating
> procedures for that scheme definition
> 
>  (iii) The ability for the authoritative entity for a particular already-registered
> scheme to change the rules for updating that scheme.  When that scheme
> definition is part of an IETF standards-track document, the usual rules for
> updating standards-track documents apply.
> 
> and that,
>  (iv) As (probably) pointed out at the end of the second paragraph of the
> introduction, URN namespaces are not part of the scope of this document.
> 
> However, if Larry, especially in his capacity as a listed co-author of 4395bis,
> reads it in a different way, I think some clarification is probably necessary
> (and that, if there is no agreement that these are really clarifications, that the
>  Clarification #1: Either restore "new" to the title and add it to the Abstract or
> insert an explicit statement in the Introduction that reflects the above, ideally
> all three.
> 
>  Clarification #2: Either clarify very precisely what "explicitly" means in the
> sentence  'URN "namespaces"
> ([RFC3406]) are specific to the "urn" scheme and are not covered explicitly by
> this specification.' (a sentence 4395bis appears to have incorporated without
> change from

Currently the URN text is unchanged from RFC 4395, and I'm getting the impression
that it might be challenging to agree on what it should say.
Personally I would be inclined to simply drop that sentence (and mention
of URN the preceding sentence) if it helped move this forward.
The URNbis spec can then take on the task of stating how this doc applies to URNs.

> "A scheme definition cannot override the overall syntax for URIs.  For
> example, this means that fragment identifiers cannot be re-used outside the
> generic syntax restrictions, and fragment identifiers are not scheme-specific."
> 
> If we can agree that this is not applicable to existing registered scheme
> definitions or updates to them and that future URN-like schemes are unlikely,
> then that is a non-issue.  If we cannot, the AppsAWG and IESG should be
> formally aware (the former has certainly been told about this in various area
> meetings) that the current consensus within URNBIS is to separate URNs from
> the semantic requirements of 3986 [2].  That position was the result of a
> difficult compromise in which the main alternative was to separate URNs
> entirely from what the WG believes are the many assumptions (most derived
> from locators) and some of the confusing language in 3986.
> 
> The paragraph quoted above appears to be new to 4395bis, does not appear
> to be noted in the appendix that lists changes, and I wonder why it was felt to
> be necessary. 

I don't think the omission was intentional.  I thought it was in the appendix,
and agree it should be added, e.g.:

14. Clarified that since, per RFC 3986, fragment identifiers are not scheme-specific
      and hence are not part of the scheme definition.

BTW, the specific text in RFC 3986 section 3.5 which says this is:
" Fragment identifier semantics are independent of the
   URI scheme and thus cannot be redefined by scheme specifications."
together with the text around that sentence which also discusses fragment identifier syntax.
So this constraint is not new in either RFC 4395 or this update.
As such, it's not a change in meaning, just an editorial change for clarity.

> Whether it is applicable to the "urn" scheme or not, the
> statement is factually false.  The only constraint the "overall syntax for URIs"
> imposes on what 3986 calls a "fragment" is that it be preceded by "#", that it
> extend to the end of the URI, and that it obey the usual rules about
> permitted characters and character
> scheme-specific are _semantic_ restrictions and, absent a good deal of
> semantics, I can't even figure out what "fragment identifiers cannot be re-
> used outside the generic syntax restrictions" might mean.

I don't think that phrase came from me, but I suspect the intent was that
fragments are defined by RFC 3986 and not by the scheme definition.

>  Clarification #3: Either explicitly exempt URNs (either by name or by "not
> applicable to existing
> registrations") or fix that paragraph to clarify the difference between syntax
> and semantic restrictions.  In the interest of correctness and technical
> accuracy, a fix seems preferable to an exemption.  The thing I think we should
> avoid (even though it would be easy from a textual standpoint) is having to
> put text in the URNBIS documents that updates 4395bis to remove this
> particular
>    time to do it is while both documents are still under consideration, i.e.,
> now.

This document needs to be consistent with RFC 3986 and what generic URI
parsers do.  Do you have a suggestion on what you're looking for in terms of
"the difference between syntax and semantic restrictions"?  I'm not quite
sure what you're getting at, but hopefully you understand my personal position
enough to suggest something I can understand.
 
> (3) I observe that 4395bis appears to considerably increase and tighten the
> binding to 3986 relative to 4395, with the above being just one example.
> Those who have been watching developments closely are aware that there
> are multiple efforts in progress in different organizations that have the intent
> to revise or even supercede 3986.  The IETF has not taken a strong position
> about those other efforts and there have apparently been AD-level
> discussions about ceding generic URI work to other
> presumed desire to avoid having changes in the status of 3986 drag this
> 4395bis specification into obsolescence, it would seem desirable to make this
> document and procedure less, rather than more, dependent on specific text
> and wording in 3986.
> Alternately, if the intent of those additional dependencies is to try to defend
> against internal or external alterations to 3986, I believe that should be
> handled up front rather than trying to use this registration specification as a
> back door.

I believe the constraint on 4395bis was indeed to depend on RFC 3986.
That is, I believe this is intentional.

>  Clarification #4/ Recommendation: The authors or others should make a
> careful pass through this document, eliminating specific dependencies on
> 3986 where possible and clarifying the intent of what remains sufficiently to
> preserve the effectiveness of this specification
> the IANA Considerations section of this document should be clear about the
> status of the registration procedure (and the registry that it specifies) should
> the references on which the spec is normatively dependent be superceded
> (that would probably be a good idea for all registration specifications that are
> not self-contained, but it is important in this case because there appears to
> be a real possibility that documents that supercede

I don't believe the former is feasible, but an IANA note as you suggest
might be feasible.  Personally, I believe that such a note would best be
authored by the IESG, should the IESG wish such a note.   However, I am
not convinced that any such note is necessary.
 
> "Schemes that are not intended to be used as locators SHOULD describe how
> the resource identified can be determined or accessed by software that
> obtains a URI of that scheme."
> 
> If this is intended to be applicable to URN or URN-like schemes that are used
> as what URNBIS has been calling "indicators", it is not clear what the
> requirement statement means.  Requirement statements without clean
> meaning vis-a-vis all of the cases to which they might apply are undesirable
> and are indeed "technical deficiencies".
>
>  Clarification #5: Either clarify the excluded cases implied by the "SHOULD" or
> explicitly exempt URNs and any similar schemes that might be developed or

It's just a SHOULD, not a MUST.  I don't think IETF specs need to enumerate
all cases where SHOULDs might not apply.   Since URIs can be used for anything
(mathematical equations, numeric values, etc.), I don't think it's possible
to try to clarify excluded cases in any meaningful way.

> (5)  The last paragraph of Section 3.3, much of it copied intact from RFC 4395,
> suggests a requirement that all "legal protocol interactions" of another
> protocol must be capable of being mapped into the URI and calls out "ftp" as
> an example.  One significant change from 4395 (not noted in the Appendix
> that lists changes) is the transformation from an informal "must"
> suggestion about the mapping model to a normative "MUST". That "MUST"
> actually contradicts the final sentence of the paragraph which begins "If not
> all legal values or protocol interactions of the base standard can be
> represented..."

That was presumably seen as synonymous and a simple editorial fix.
However I agree with the point that the last sentence envisions the lack of the MUST
in which case it should be SHOULD for consistency.  As editor of the current version,
I can say there was no intent I am aware of to change the actual meaning.
Hence I think s/MUST/SHOULD/

> This raises two issues.  First, if 4395bis (especially its normative requirements)
> is to be applied retroactively to existing registrations, then the registration of
> the ftp scheme is now invalid (whether that last sentence is considered as a
> path to an exception or not).  First, the discussion in RFC 1738, which is
> referenced as the definition of the scheme from the IANA registry, is not
> complete relative to the functionality of the FTP protocol as of the time RFC
> 1738 was written and does not explain the exceptions.  It even says that it is
> incomplete with the rather magical sentence (in Section 3.2.2 of RFC 1738)
> The IETF has also chosen to standardize a number of extensions to FTP
> (including, in these IPv6 and security-conscious days, RFCs 2428 and 4217)
> that have not been reflected in either the registration or in an update to RFC
> 1738.  Second, even for new registrations, changing informal guidance that
> happens to use the word "must" to a normative absolute requirement (with
> "MUST") should require much more careful review and evaluation by the
> community than this change appears to have gotten (especially given the
> apparent contradiction it introduces).
> 
> FWIW, I haven't done a careful review, but it is not clear to me that even the
> "http:" scheme, as reflected in the IANA registry, would be considered valid by
> the criteria in 4395bis given functionality changes introduced by HTTP2 and
> other relatively recent changes and extensions.
> 
> I note, also FWIW, that Section 3.4 is much more balanced and reasoned and
> that it uses "SHOULD" consistently and not "MUST".

And I agree that section 3.3 should do the same.

> Considerations") would also invalidate a number of existing registrations.

There is no intent to be retroactive, only to apply to new requests to IANA
(whether those are requests for new schemes, or new requests to update
existing schemes.)

> 
>  Clarification #6: This example, which has nothing to do with URNs or, unless
> the long-expired draft-hoffman-ftp-uri is considered, any other active URI-
> defining work in the IETF, points out another reason why it is important that
> this 4395bis document explicitly disclaim applicability to any already-
> registered scheme or updates to it except as the most general guidance and
> recommendations of issues to
>    be considered.
> 
>  Clarification #7: The MUST in the cited paragraph should be, at most, a
> "SHOULD" or the paragraph should be reworded to correctly reflect realistic
> intent.

Again, agreed (and done in my local copy).

>  Clarification #8/Recommendation: The list of Changes in Appendix A should
> be expanded to reflect all changes from general guidance (expressed in, e.g.,
> "must" or
> "should") to normative requirements.  Treating such changes as editorial
> corrections is appropriate only when the context clearly indicates normative
> intent and the changes do not introduce contradictions either within the text
> or to established practices.

Added (in my local copy) #14 as I suggested above.

> (6) URN work has made it clear that defining the scope of applicability of a
> URI scheme is, at best, a shared responsibility between whatever
> documentation defines the scheme and the documentation that defines the
> referencing context.
> Attempts to shift all of that responsibility to the scheme definition, as Section
> 3.5 can be interpreted to do, is unrealistic if only because the scheme
> definition cannot predict referencing contexts that might be defined or
> redefined in the future.  Given that the current text uses a "SHOULD", it is
> probably ok, but a clarification that contexts that incorporate URI references
> also bear some responsibility for describing the schemes that are valid and
> meaningful (preferably on an inclusion basis) would be helpful to avoid
> outrageous claims in the future.  Anyone contemplating a 4395ter might
> consider whether adding an "applicable application, protocol, or context"
>  Clarification #9: Add a sentence to Section 3.5 to clarify that its provisions do
> not eliminate the requirement for the applications and/or protocols from
> which URIs are used to discuss the schemes that are (or are not) relevant and
> appropriate for use in those contexts.

How's this:
NEW: This does not obviate the need for documentation on applications and/or
NEW: protocols to discuss URI schemes relevant to them.

> (7) In my capacity as someone who is supposed to know a bit about i18n
> issues, I think I understand the intent that motivated the inclusion of the last
> paragraph of Section 3.6.
> However, after reading that paragraph several times, I am not sure what it
> actually means.  If the term "variant" (which I would encourage authors to
> avoid) is interpreted in its ICANN usage or even as defined in Section 7.2 of
> RFC 6365, I am _sure_ I don't know what the paragraph means.
> 
>  Clarification #10: That paragraph needs to be rewritten and carefully checked
> by i18n experts.  Encouraging the registration to make a clear statement
> about normalization and/or other comparison-related issues would probably
> be desirable.

Is this better:
NEW: Percent-encoded character sequences are automatically included by
NEW: definition for characters given in IRI productions.

> (8) Section 7.3 is not explicit that an updated registration can change the
> mechanism for future updates, nor that registrations, especially those
> associated with IETF documents, can specify update/change mechanisms
> different from those specified in this
> Since recent discussions have called both into question, I think some
> clarification is needed.

Personally I still think that both are obvious (Larry's email notwithstanding)
and that further explanation is not required.  That is, I still agree with
the John of last month :)
 
>  Clarification #11: Add text to Section 7.3 to make it explicit that scheme
> registrations MAY specify updating procedures that are more specific than
> those outlined in 4395bis, including identifying other approval mechanisms or
> responsible parties, and that scheme registration updates may modify the
> updating mechanism as well as other aspects of the registration.

I'm not even sure what that means after reading it twice.
  
>  Clarification #12: In the template shown in Section 7.4, add to the "Change
> controller:" entry a statement equivalent to "Any special considerations
> about updating or updating procedures should also appear as part of this
> item."

I'm not convinced that's necessary (not sure what the WG thinks) but this
seems like a new issue and so I'm hesitant to delay for something that would
be a MAY statement anyway.   I.e., doesn't sound like a blocker to me.

> (9) Further evidence that this document is confused about existing
> registrations, retroactive application, and its own
> registration that is specified in that section does not appear to conform to
> the "fields that MUST be supplied" requirements of Section 7.4: there is no
> contact given and the "Change controller" field is identified as
> "Author/Change controller".
> If that flexibility was intended by Section 7.4, the document should say so.

Oops, I'll take the blame for that one.  I held the pen on doing the latest updates
and I missed section 8 when I updated section 7.4.  Thanks for pointing that out,
I've corrected section 8 in my local copy.

Thanks for the careful review,
Dave

---

From: Dave Thaler <[email-masked]>
Date: Wed, 8 Apr 2015 01:05:41 +0000

Correct as noted above.

 

As such, it's not a change in meaning, just an editorial change for clarity

---

From: Barry Leiba <[email-masked]>
Date: Wed, 8 Apr 2015 15:28:28 -0400

> particular, draft-ietf-urnbis-rfc2141bis-urn and have been

John (and others), please check the -06 version, looking especially at
the new last paragraph of Section 7.1.  I believe that takes care of
this case by codifying how Graham already handles registration
requests that come from IETF working groups.

For the specific case of urnbis, consensus on 2141bis would allow it
to specify how urn: registrations work, independent of what's said
here.  I would say that if 2141bis specifically contradicts something
here, it should explicitly call that out, to be absolutely clear about
it.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 8 Apr 2015 15:28:28 -0400

Barry

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Apr 2015 10:41:33 -0400

--On Wednesday, April 08, 2015 15:28 -0400 Barry Leiba
<[email-masked]> wrote:

> John (and others), please check the -06 version, looking
> especially at the new last paragraph of Section 7.1.  I
> believe that takes care of this case by codifying how Graham
> already handles registration requests that come from IETF
> working groups.

That section, and the other changes from -05, represent huge
improvements.  Thanks.

> For the specific case of urnbis, consensus on 2141bis would
> allow it to specify how urn: registrations work, independent
> of what's said here.  I would say that if 2141bis specifically
> contradicts something here, it should explicitly call that
> out, to be absolutely clear about it.

That is fine.  I would appreciate it if you and/or others who
are relevant would figure out, now, if 2141bis said something
contradictory to what is said in
draft-ietf-appsawg-uri-scheme-reg whether it should be noted as
updating this document.   I don't care what the answer is; I
just do not want to have a time-consuming late-stage controversy
about the issue.

More important, neither the changes nor your note address the
particular issue that caused my review and concerns about
draft-ietf-appsawg-uri-scheme-reg.  The issue was the claim that
this document imposed additional constraints or requirements in
addition to those of RFC 3986, requirements that could (or did)
invalidate what the URNBIS WG is trying to do with
draft-ietf-urnbis-semantics-clarif.  

I believe the key issue is that, as far as the _syntax_
specified in RFC 3986 is concerned, there is a syntax component,
given the name "fragment" in the defining production, that,
informally, is delimited by the first appearance of "#" in a URI
and that extends to the end of the URI.  Anything more --
bindings to schemes, relationships to media types, even the
binding of the term "fragment" to anything one might find in a
dictionary-- are matters of semantics (or maybe something else)
but not syntax. 

Consequently, when this document says, in the second paragraph
of Section 3,

we have at statement that is at least confusing (if not a
logical fallacy) and one that creates an opportunity for
arguments about what an effort to specify or update a URI scheme
(even a standards-track one associated with at WG) attempts to
do.   In addition to whatever was intended, the statement could
be read as "fragments are required to be allowed with all URI
schemes and no individual scheme can prohibit them".  I'm fairly
confident that is not what the authors of either this document
or 3986 intended, but, if that sort of ambiguity exists, it is
unreasonable to claim that there is informed community consensus
about this document.

I note that the following sentence and syntax excerpt is
completely consistent with my comment.  It shows '"#" fragment'
as optional, which implies that it can be prohibited on a
scheme-specific basis.  The example text just confuses things.

Note too that every syntax-defining metalanguage I've works
with, from original BNF (which does not allow brackets of
equivalent to optional parts) through ABNF and beyond, treats
the sequence

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

And

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

as specifying _exactly_ the same syntax.  The distinction may be
useful for clarity but makes no syntax distinction.

If the example simply said something like:

	'For example, this means that the "#" character cannot be
	used except to introduce what RFC 3986 describes as a
	fragment, and URI schemes cannot change that
	interpretation of the syntax.'

with or without an additional sentence saying:

	'Particular scheme definitions may disallow use of
	fragments entirely.'

then I don't believe we would have a problem.

While I think this document could be improved, especially wrt to
statements like the above where the example is not really an
illustration of the restriction statement and attempts to use
syntax productions to make distinctions that the productions
don't support, I recognize the value of what the document is
trying to accomplish and, as I have said earlier, do not want to
hold it up over fine points of meaning and boundaries between,
e.g., syntax and semantics.   At the same time, it cannot be in
the IETF's best interest to have someone complicate the very
difficult issues and choices facing the URNBIS WG by using this
document to play "gotcha", especially if the player is one of
the document's co-authors.

So I continue to believe that it is necessary to do at least one
of the following:

(1) Correct this document to remove all statements or so-called
examples that appear to impose restrictions not present in 3986
and all ambiguities of the variety illustrated above.

(2) Alter this document to exclude existing schemes (including
revisions of their definitions) whose definitions are included
in or normatively referenced by standards-track documents.

(3) Alter the document to make it clear that a standards-track
document may treat this document as advisory and override
anything it says by providing a clear explanation of why it is
doing so _and_ make a clear public note, in the tracker or an
IESG statement, that language in this document can not by used
as an authority to block discussions of alternate strategies in
IETF WGs or other standards-track efforts.

(4) Hold this document until 2141bis (and associated documents)
are ready and then issue a new Last Call on the two documents
together.  Or, perhaps equivalently in practice, hold this
document until the APPAWG and URNBIS WG can reach joint
consensus about what it should say, at least on the subject of
revisions to existing URH scheme definitions.

>From my point of view, option 4 is the least desirable of that
collection.

best,
    john

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Apr 2015 10:41:33 -0400

And

collection.

best,
    john

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 9 Apr 2015 12:13:30 -0700

> dictionary-- are matters of semantics (or maybe something else)

They are a product of what it is to be a URI.  Whether you call that
syntax or semantics is irrelevant.

> do.

No, it is a statement of fact.  Wherever a URI might be used as a
protocol element, there is an explicit role assigned to the fragment
portion of the syntax that cannot be redefined by any scheme.
Any claim to the contrary, whether that be by an individual or
by IETF standards track working group consensus, is wrong.

This does not, however, have any impact on the ability of the urn
scheme to define identifiers that exclude a fragment, nor on the
use of urn identifiers with arbitrary fragments as defined by 3986.
The fragment is part of the overall identifier -- it just isn't
dependent on the scheme and cannot be forbidden by a scheme.

The semantics, if any, for a fragment depend entirely on how the
identifier is used.  If it is used as an HTTP request-target, the
fragment portion will not be sent, regardless of the URI scheme.
The same is true for other retrieval protocols.  If the identifier
is never used for retrieval, the fragment's semantics are unbounded.

Now, you might claim that "urn" schemes are not intended for retrieval.
Even if that were true (it isn't), it still wouldn't matter.  Given any URI,
an HTTP request can be used to attempt retrieval of a representation,
which means that any URI (sans fragment) can be used for retrieval
if it is possible to configure a suitable service for such resolution,
where "suitable" is judged by the provider and users of that service,
not by the working group that defines the identifiers.

No scheme definition can escape those facts, which is why both 3986
and the scheme registration document say so explicitly.  This does
not prevent anyone from using (or not using) fragments with some
urn identifiers.  It only prevents them from escaping how they are
processed when used as a URI protocol element, since that processing
is independent of scheme.

>   In addition to whatever was intended, the statement could

Of course that is what 3986 intended.  We have archived history of
the URI protocol discussions.  None of this should be a surprise.

> useful for clarity but makes no syntax distinction.

Yes, the URI syntax specifies that fragment is optional.  But the syntax
does not specify the fragment processing behavior, which is what you are
claiming the scheme has some control over.  As stated, the presence
or absence of fragment is syntax independent of the scheme.
Hence, scheme definition documents have no ability to control the
use or absence of fragments.

> then I don't believe we would have a problem.

That would be factually wrong.  Go ahead and try it in software.
A document might specify all sorts of requirements associated with
the scheme it defines, and some users might even adhere to them,
but that won't change client behavior when processing a URI protocol
element.

> revisions to existing URH scheme definitions.

John, the only appropriate thing to do here is, once again, repeat
that 2141bis contains significant errors, and that failing to fix
those errors in your document does not, in any way, justify that
other parts of the IETF that have correctly defined their protocols
be held up until the URNbis working group decides to listen to the
input they have already received.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 9 Apr 2015 12:13:30 -0700

....Roy

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 09 Apr 2015 21:20:56 -0600

> portion of the syntax that cannot be redefined by any scheme.

My understanding of "role" here is that you probably intend it to denote 
a specific semantic meaning.

> dependent on the scheme and cannot be forbidden by a scheme.

If I understand this correctly, it means that no scheme can say that 
URIs in general cannot contain fragment identifiers. But no scheme 
definition tries to do that, AFAIK.

> which means that any URI (sans fragment) can be used for retrieval

What does it mean to make an HTTP request for, say, a SIP URI?

> and the scheme registration document say so explicitly.

I don't see anything in RFC 3986 that says a URI must be "resolvable" 
via HTTP.

> This does

But IMHO it doesn't always make sense to use URIs with any random URI 
scheme in any given URI protocol slot. What does it mean to place a 
'sip' or 'data' or 'iax' or 'msrp' (etc.) URI in the 'xmlns' protocol 
slot in XML? What does it mean to place an 'http' URI in the Request-URI 
protocol slot in SIP? (In fact, RFC 3261 says that only a SIP or SIPS 
URI is allowed there.) To say that every protocol slot in which a URI 
can appear must accept URIs from all schemes seems off-base to me.

> the URI protocol discussions.  None of this should be a surprise.

No scheme can prohibit fragments in that scheme as a matter of "local 
policy" (as it were), or no scheme can prohibit fragments in general?

<snip/>

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 09 Apr 2015 21:20:56 -0600

<snip/>

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 9 Apr 2015 21:42:44 -0700

> 
> On Apr 9, 2015, at 8:20 PM, Peter Saint-Andre - &yet <[email-masked]> wrote:
> 
> My understanding of "role" here is that you probably intend it to denote a specific semantic meaning.

No. It is a piece of syntax reserved for a specific role in the processing of hypertext references. It might gain semantics when used in a certain way, but it doesn't have semantics in and of itself (or at least no more semantics than any other name).

> If I understand this correctly, it means that no scheme can say that URIs in general cannot contain fragment identifiers. But no scheme definition tries to do that, AFAIK.

The fragment doesn't have anything to do with the scheme, period. This is a layer violation as obvious as defining TLS within HTTP. Yes, we do that some times, but that doesn't make it right. If you don't want that role to be in effect, then don't use fragment.

> What does it mean to make an HTTP request for, say, a SIP URI?

What does it mean to make a Web request for a SIP URI? It doesn't have to be using HTTP. If you can define what it means for SIP, then it can be represented via HTTP as well. If not, then the attempt will fail. Nevertheless, the attempt will exclude the fragment because that information is reserved for client-side processing (if any).  

If such a URI is never used in that fashion, then no semantics are assumed for the fragment. This does not mean a scheme like sip can redefine or disallow fragments, since it doesn't control how its identifiers might be used.

> I don't see anything in RFC 3986 that says a URI must be "resolvable" via HTTP.

There is no need for it to say anything like that. It does not change the fact that the fragment has a specific role when present in a URI. It is a uniform syntax for a reason.

> But IMHO it doesn't always make sense to use URIs with any random URI scheme in any given URI protocol slot. What does it mean to place a 'sip' or 'data' or 'iax' or 'msrp' (etc.) URI in the 'xmlns' protocol slot in XML? What does it mean to place an 'http' URI in the Request-URI protocol slot in SIP? (In fact, RFC 3261 says that only a SIP or SIPS URI is allowed there.) To say that every protocol slot in which a URI can appear must accept URIs from all schemes seems off-base to me.

It doesn't matter. To the extent that some use is not allowed or simply doesn't make sense, the fragment remains free of any semantics and can be used as a name. It can therefore be used with such URIs even if the scheme is completely unaware of its possible existence.

> No scheme can prohibit fragments in that scheme as a matter of "local policy" (as it were), or no scheme can prohibit fragments in general?

No scheme can prohibit fragments. They are not part of the scheme's syntax.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 9 Apr 2015 21:42:44 -0700

....Roy

---

From: Graham Klyne <[email-masked]>
Date: Fri, 10 Apr 2015 08:43:15 +0100

> If such a URI is never used in that fashion, then no semantics are assumed for the fragment. This does not mean a scheme like sip can redefine or disallow fragments, since it doesn't control how it…

My understanding is that a request to an HTTP server may convey a SIP 
request-URI, and it's up to the configuration of the receiving (gateway?) server 
what it does with it.

(Was it not once common to issue ftp: requests through HTTP in this way?)

I believe that the HTTP prohibition on including a fragment identifier would 
still apply here.

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Fri, 10 Apr 2015 08:43:15 +0100

#g
--

---

From: Barry Leiba <[email-masked]>
Date: Fri, 10 Apr 2015 11:38:11 -0400

> No scheme can prohibit fragments. They are not part of the scheme's syntax.

We continue to have a confusion between syntax and semantics here.

I absolutely agree that no scheme can say that fragments are
syntactically invalid, because the schemes do not control the syntax
of a URI.

But a scheme can certainly say that fragments make no semantic sense
within that scheme, and that if a URIs uses that scheme and contains a
fragment, it is not a well formed URI within that scheme.

It's rather like saying that English words are composed of characters
from the set "abcdefghijklmnopqrstuvwxyz", and, therefore, the string
"qwx" is a valid piece of an English word (syntax)... but that, in
fact, no valid English words contain "qwx" (semantics).

That's not a layering violation at all -- it has to be up to the
scheme to say what the semantic meaning of a fragment is within that
scheme, or whether fragments have any meaning at all.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Fri, 10 Apr 2015 11:38:11 -0400

Barry

---

From: Matthew Kerwin <[email-masked]>
Date: Sat, 11 Apr 2015 12:40:26 +1000

> fragment, it is not a well formed URI within that scheme.
RFC 3986, S3.5: "​The fragment's format and resolution is therefore
dependent on the media type [RFC2046] of a potentially retrieved
representation, even though such a retrieval is only performed if the
URI is dereferenced.  If no such representation exists, then the
semantics of the fragment are considered unknown and are effectively
unconstrained.  Fragment identifier semantics are independent of the
URI scheme and thus cannot be redefined by scheme specifications."

To me that says that schemes cannot touch fragments at all, except
indirectly -- through representation retrieval. In the case of 'http' that
actually makes it the purview of the protocol (not the scheme), however in
'file' it's a bit fuzzier because representation retrieval doesn't have a
protocol to lean on. For URN it's completely obscure to me, because names
aren't inherently dereferenceable (?). I interpret it as: don't mention
fragments at all.

> scheme, or whether fragments have any meaning at all.
​The analogy is over-simplified. If I were to write "Section 4.8.1 of RFC
1045" in some English prose, the syntax and semantics of English language
may lead us to understand that "RFC 1045" is a technical document, and
"Section ... of ..." is a fragment reference, so the question becomes: what
types of fragments can be referenced within a technical document?

If the 'English language' also defines the structure of 'technical
documents' then it can say that they contain sections, tables, and images,
for example; but if not then there's no way to know that "Quadrant 3 of RFC
6215" is nonsense, even though "Quadrant ... of ..." is also a fragment
reference.

I think it's up to the scheme to see what (if any) representations can
exist, and then those representations have to say what the fragment
semantics mean. The best the scheme can say is: "All representations are
SVG, therefore fragment semantics are defined by the W3C." Or: "There are
no representations, therefore fragments are undefined."

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Matthew Kerwin <[email-masked]>
Date: Sat, 11 Apr 2015 12:40:26 +1000

Cheers

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 10 Apr 2015 20:44:34 -0700

> On Apr 10, 2015, at 8:38 AM, Barry Leiba <[email-masked]> wrote:
> 

No, they can't, or at least they cannot say that truthfully.

> fact, no valid English words contain "qwx" (semantics).

Sorry, you've lost me.

It is more like saying that, because host and port are adjacent to each other in
the syntax, it is therefore possible for DNS to specify what ports are allowed.

> scheme, or whether fragments have any meaning at all.

It has nothing to do with the scheme. Nothing whatsoever. It is true that there
are many resources, regardless of scheme, for which a fragment identifier wouldn't
have much practical purpose other than as a name, but that's only because
nobody has found a reason to resolve them yet. In most cases, this is because
deployment of the scheme is so small that it isn't worth anyone's bother to create
a gateway for information about its identified resources.

The problem is that if we let people write incorrect statements about fragments
within scheme specifications, we lose interoperability around one of the main
extension points in Web architecture. We lose the ability to process the results
of interactions independently of the protocols and systems used to obtain them.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 10 Apr 2015 20:44:34 -0700

Sorry, you've lost me.

....Roy

---

From: John C Klensin <[email-masked]>
Date: Mon, 13 Apr 2015 15:05:20 -0400

Roy,

I think I've having serious trouble with the position you are
taking but, before I overreact (again?) and confuse things
further, I would appreciate your clarifying something for me.

Let's put 2141bis aside for a moment and go back to 2141 itself.
Section 2 of 2141 says (trimming irrelevant material):

	All URNs have the following syntax [...]:

       <URN> ::= "urn:" <NID> ":" <NSS>

	The Namespace ID determines the _syntactic_
	interpretation of the Namespace Specific String (as
	discussed in [1])."

Reference [1] points to an I-D that I assume evolved into RFC
2276.

2141 then goes on to say:

   <NSS>   ::= 1*<URN chars>
   <URN chars> ::= <trans> |
        "%" <hex> <hex>
   <trans> ::=  <upper> | <lower> | <number> | <other> |
        <reserved>
   <hex>   ::= <number> | "A" | "B" | "C" | "D" | "E" |
       "F" | "a" | "b" | "c" | "d" | "e" | "f"
   <other>  ::= "(" | ")" | "+" | "," | "-" | "." |
       ":" | "=" | "@" | ";" | "$" | "_" | "!" | "*" | "'"

Note that, if fragments (or anything delimited by a leading "#")
were allowed, the above would make them part of the NSS.  If I
understand you correctly, that is invalid because, in the syntax
of 3986, the 2141 NSS is necessarily a substring of hier-part,
while 3986 appears to allow "#" (and a fragment) only after the
hier-part.  Is that correct?

And, in section 2.3,

   The reserved character set is:

   <reserved>    ::= '%" | "/" | "?" | "#"

   [...]
  2.3.2 The other reserved characters

  RFC 1630 [2] reserves the characters "/", "?", and "#" for
  particular purposes. The URN-WG has not yet debated the
  applicability and precise semantics of those purposes as
  applied to URNs. Therefore, these characters are RESERVED
  for future developments.  Namespace developers SHOULD NOT
  use these characters in unencoded form, but rather use the
  appropriate %-encoding for each character.

Now, am I correct in my understanding that the above statement
is invalid on its face because no URI scheme can prohibit the
use of fragments, even to the extent of saying that they SHOULD
NOT be used?

Am I also correct in my understanding that the rule(s) that
invalidate the above have nothing to do with any of 4395bis, RFC
4995, or even RFC 3986 but depend only on  RFC 1738 or possibly
RFC 2396?

If any of that is not correct, could you please explain?

thanks,
    john

--On Friday, April 10, 2015 20:44 -0700 "Roy T. Fielding"
<[email-masked]> wrote:

>> syntactically invalid, because the schemes do not control the
>> syntax of a URI.
>> 
>> But a scheme can certainly say that fragments make no
>> semantic sense within that scheme, and that if a URIs uses
>> that scheme and contains a fragment, it is not a well formed
>> URI within that scheme.
> 
>...

---

From: John C Klensin <[email-masked]>
Date: Mon, 13 Apr 2015 15:05:20 -0400

Roy,

   <NSS>   ::= 1*<URN chars>

And, in section 2.3,

   [...]

thanks,
    john

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 13 Apr 2015 23:28:17 -0500

> On Apr 13, 2015, at 2:05 PM, John C Klensin <[email-masked]> wrote:
> 
> Roy,
> 

Umm, not sure I understand the question.  The syntax above should not allow
a fragment delimiter "#" to be part of the NSS, which should mean that the <URN>
would match the absolute-URI production of 3986.  In other words, it would be
valid if it excludes the fragment.

  http://tools.ietf.org/html/rfc3986#section-4.3

>   <reserved>    ::= '%" | "/" | "?" | "#"

And there is the bug.  In RFC1808 and RFC2396, the "#" wasn't in the reserved set.
It was in the punctuation or delims set, which meant it was never allowed outside
of the specific occurrence as the fragment delimiter.  In RFC3986, the "#" is in
the reserved set, but the reserved set is for illustrative purposes only in both
2396 and 3986 (the URI grammar itself does not make use of the reserved production).

  http://tools.ietf.org/html/rfc2396#section-2.4.3

> use of fragments, even to the extent of saying that they SHOULD

Yes.  More to the point, it should have said that they MUST NOT be
in NSS, since the fragment is not part of the URL, and they should have
been referring to RFC1808 (a proposed standard at that time), not
RFC1630 (an informational RFC).  In general, though, this was understood
and expected to be resolved as part of the development of RFC2396 and
finally in the form of RFC3986.  The IETF did a lot of work on URI
in the 18 years since RFC2141.

> 4995, or even RFC 3986 but depend only on  RFC 1738 or possibly

RFC1808, RFC2396, and RFC3986 (in succession).  We did have these discussions
about fragment, each time, which is why the requirement in RFC3986 (sec 4.3)
is very clear (IMO), and why it is repeated in 4395bis.  It is specified
that way because scheme-specific fragment is neither desirable (from the
architecture PoV) nor interoperable (most software separates the fragment
as part of reference parsing, before doing anything with the scheme).

Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <http://www.adobe.com/>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 13 Apr 2015 23:28:17 -0500

Cheers,

---

From: Sean Leonard <[email-masked]>
Date: Wed, 15 Apr 2015 21:54:54 -0700

> a gateway for information about its identified resources.

I agree with Barry.

The scheme transitively defines the semantic meaning of fragments because the scheme defines the kinds of resources (if any) that are identified by it. Those resources may or may not have Internet media types, and those resources may or may not assign semantic meanings to fragments.

mailto: defines a URI scheme that does not identify representations of anything; it is used to launch a compose window to create new mail. (Arguably a mailto: URI identifies a mailbox.) Therefore fragment identifiers have no semantic meaning in mailto: because mailto: doesn’t use them.

[RFC6068] says:
   Note that this specification, like any URI scheme specification, does
   not define syntax or meaning of a fragment identifier (see [STD66]),
   because these depend on the type of a retrieved representation.  In
   the currently known usage scenarios, a 'mailto' URI cannot be used to
   retrieve such representations.  Therefore, fragment identifiers are
   meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be
   ignored upon resolution.  The character "#" in <hfvalue>s MUST be
   escaped as %23.

This text is entirely consistent with Barry’s point. The scheme may not define the semantics of the fragment directly, but it defines the resources (representations), which in turn define the fragments.

Sean

PS I could be wrong but [RFC3966] looks like it permits the # character in the tel: URI in the path part. Is there a legacy reason for that, or just an oversight?

---

From: Sean Leonard <[email-masked]>
Date: Wed, 15 Apr 2015 21:54:54 -0700

I agree with Barry.

[RFC6068] says:

Sean

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 16 Apr 2015 12:58:15 -0500

> On Apr 15, 2015, at 11:54 PM, Sean Leonard <[email-masked]> wrote:
> 

You are confusing resources with representations.  Resources do not have media types,
though they might have representations that are consistently the same media type.
Resources don't even need to have representations.

Regardless, the scheme does not define the kinds of representations. It only defines the
rules for name allocation within a uniform syntax for that name.  What kinds of
representations are so named depends *entirely* on how the identifiers are used, not on
the scheme.  For example, a VIN (physical identifier assigned to a vehicle by its
manufacturer) is clearly intended to uniquely identify a car.  However, its primary
uses are to indirectly identify registration records, odometer readings, and insurance
policies.  If a urn namespace for vin is assigned and a urn:vin: is used in HTTP for a
GET of a representation, the response will not be a car.

> mailto: defines a URI scheme that does not identify representations of anything; it is used to launch a compose window to create new mail. (Arguably a mailto: URI identifies a mailbox.) Therefore f…

Actually, what it identifies is a pre-defined template for an email message.
Fragment identifiers are rarely used here because implementations are inconsistent,
not because there is anything unusual about the scheme.  Note that mailto is *also*
used for other things, like mailbox identifiers, in which the context of use clearly
does not support the use of fragments (just like they don't support subject or body
definitions within query).  That's fine.

>   ignored upon resolution.  The character "#" in <hfvalue>s MUST be

Obviously, that is a bug in that spec.  An errata should be attached to it.
For example,

   mailto:[email-masked]#cc

is a valid use of fragment for the mailto URI (it instructs the user agent to
place the input context on the cc field after presentation of the template).

> This text is entirely consistent with Barry’s point. The scheme may not define the semantics of the fragment directly, but it defines the resources (representations), which in turn define the fragm…

The text violates the requirements of STD66, the standard upon which it is
supposed to be entirely dependent.  It is an obvious bug,

> Sean
> 
> PS I could be wrong but [RFC3966] looks like it permits the # character in the tel: URI in the path part.

It does not.  Read the text around gen-delims in section 2.2.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 16 Apr 2015 12:58:15 -0500

....Roy

---

From: Barry Leiba <[email-masked]>
Date: Thu, 16 Apr 2015 14:25:01 -0400

> That section, and the other changes from -05, represent huge

Great.

> dictionary-- are matters of semantics (or maybe something else)

I understand the concern here, and as I read the rest of the
conversation I see that we still have controversy about details such
as fragment vs syntax vs semantics, and such.

That said, I don't think that controversy affects this document.  I
think this document says what it needs to say about the registration
and update of URI schemes, and the roles of the DE and of working
group/community consensus.  I don't think there's a benefit to holding
up this document for the resolution of those other issues, which we'll
continue bashing around here and in the urnbis working group.

So I plan to push "GO" on this document imminently.  If you think this
absolutely *must* be resolved before this document is published,
please say why we can't defer it to discussion of 2141bis, an update
to 3986, or some other such.

We do need this uri scheme registration update -- which primarily
relaxes and clarifies existing rules -- and I don't want to make it
wait longer if we can handle the controversies elsewhere.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 16 Apr 2015 14:25:01 -0400

Great.

Barry

---

From: John C Klensin <[email-masked]>
Date: Thu, 16 Apr 2015 15:53:33 -0400

--On Thursday, April 16, 2015 14:25 -0400 Barry Leiba
<[email-masked]> wrote:

>> specified in RFC 3986 is concerned, there is a syntax
>> component, given the name "fragment" in the defining
>> production, that, informally, is delimited by the first
>> appearance of "#" in a URI and that extends to the end of the
>> URI.  Anything more -- bindings to schemes, relationships to
>> media types, even the binding of the term "fragment" to
>> anything one might find in a dictionary-- are matters of
>> semantics (or maybe something else) but not syntax.
> 
> conversation I see that we still have controversy about
> details such as fragment vs syntax vs semantics, and such.
> 
> That said, I don't think that controversy affects this
> document.  I think this document says what it needs to say
> about the registration and update of URI schemes, and the
> roles of the DE and of working group/community consensus.  I
> don't think there's a benefit to holding up this document for
> the resolution of those other issues, which we'll continue
> bashing around here and in the urnbis working group.
> 
> So I plan to push "GO" on this document imminently.  If you
> think this absolutely *must* be resolved before this document
> is published, please say why we can't defer it to discussion
> of 2141bis, an update to 3986, or some other such.
> 
> We do need this uri scheme registration update -- which
> primarily relaxes and clarifies existing rules -- and I don't
> want to make it wait longer if we can handle the controversies
> elsewhere.

To repeat what I have tried to say before, I think there is one
important distinction to be made here.  To state it as narrowly
as I can, either this document imposes requirements on existing
schemes and revisions of them that 3986 does not or it doesn't.
If it does impose new requirements, then, according to
long-established IESG requirements, it must indicate that it
updates 3986 and explain the nature of the update/change(s).  In
addition and depending on what that text says, it is likely to
be inevitably bound to the controversies.   If it does not
impose new requirements, then I'm comfortable letting this
document go forward based on your assurances (and, implicitly,
that of the IESG) that future arguments that cite this document
in discussions of the controversies to which you refer will be
disregarded a without substance.

Put differently, either those controversies are rooted in the
requirements of, and "details such as fragment vs syntax vs
semantics" based on, 3986, or they are about some combination of
3986 and this document.  If the first, as you seem to believe
(and, btw, I agree), then the controversy does not affect this
document and it should go forward.   If the second, then this
document is inherently part of the controversy and it is
inappropriate for it to go forward at this time.

        john

---

From: John C Klensin <[email-masked]>
Date: Thu, 16 Apr 2015 15:53:33 -0400

john

---

From: Barry Leiba <[email-masked]>
Date: Thu, 16 Apr 2015 16:04:19 -0400

> inappropriate for it to go forward at this time.

Thanks for succintifying things.

I think the answer is that this document does not update 3986, and
does not intend to impose new requirements.  I think the controversies
are purely about 3986, and not about what this document is doing.

I will wait for confirmation of that from a document author or two...
or refutation of it from anyone who thinks I'm wrong about where this
document sits.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 16 Apr 2015 16:04:19 -0400

Barry

---

From: Dave Thaler <[email-masked]>
Date: Thu, 16 Apr 2015 20:39:10 +0000

Barry Leiba writes:
> I think the answer is that this document does not update 3986, and does not
> intend to impose new requirements.  I think the controversies are purely
> about 3986, and not about what this document is doing.
> 

I agree with Barry and above matches what I've previously stated on the list.

Dave

---

From: Tony Hansen <[email-masked]>
Date: Thu, 16 Apr 2015 16:46:23 -0400

> or refutation of it from anyone who thinks I'm wrong about where this

Just now, I've re-reviewed all references to 3986 within 
draft-ietf-appsawg-uri-scheme-reg-06 and don't see anywhere that it 
should be construed as >updating< 3986. There are lots of places where 
people are directed to looking at 3986 and 3987, and a thorough 
understanding of those is needed to fully appreciate some of the things 
being said in here. But if there's ANY doubt about us NOT updating them, 
is there a need to explicitly state that, say in the introduction?

     Tony Hansen

---

From: John C Klensin <[email-masked]>
Date: Thu, 16 Apr 2015 18:35:30 -0400

--On Thursday, April 16, 2015 16:46 -0400 Tony Hansen
<[email-masked]> wrote:

> draft-ietf-appsawg-uri-scheme-reg-06 and don't see anywhere
> that it should be construed as >updating< 3986. There are lots
> of places where people are directed to looking at 3986 and
> 3987, and a thorough understanding of those is needed to fully
> appreciate some of the things being said in here. But if
> there's ANY doubt about us NOT updating them, is there a need
> to explicitly state that, say in the introduction?

In the spirit of moving on, I'd prefer to avoid requiring
another rev and will happily settle for the assurance that
everyone involved will provide support for my pushing back if
anyone stands up and says "you can't do <X> in URNs because
draft-ietf-appsawg-urn-scheme-reg clarified 3986 to prohibit it".

    john

---

From: Barry Leiba <[email-masked]>
Date: Thu, 16 Apr 2015 21:22:39 -0400

> draft-ietf-appsawg-urn-scheme-reg clarified 3986 to prohibit it".

Thanks, John!  I'm off to ask the Secretariat to make the approval announcement.

Barry

---

From: Graham Klyne <[email-masked]>
Date: Fri, 17 Apr 2015 21:16:43 +0100

> draft-ietf-appsawg-urn-scheme-reg clarified 3986 to prohibit it".

I assume you meant "draft-ietf-appsawg-uri-scheme-reg" above (not "*-urn-*"). 
I'd be pushing back on any aspect which appeared to change what is required by 
RFC3986.

(All of this leaves me wondering if it would be helpful to state that explicitly 
in the registration document, but at this stage in the process I'm reluctant to 
introduce suggestions for shadow-dodging changes.)

#g
--

---

From: John C Klensin <[email-masked]>
Date: Sat, 18 Apr 2015 08:28:30 -0400

--On Friday, April 17, 2015 21:16 +0100 Graham Klyne
<[email-masked]> wrote:

>>> that it should be construed as >updating< 3986. There are
>...

> I assume you meant "draft-ietf-appsawg-uri-scheme-reg" above

Yes.  Sorry.

>  I'd be pushing back on any aspect which
> appeared to change what is required by RFC3986.

Then we are in agreement (!).

Because my concern still seems to be unclear, let me try to
explain it in a different way and as a series of logical
statements and propositions.  I do not believe that anything in
the first three bullets below should be controversial.  The
fourth one may be but, IMO, only if long-established principles
and terminology in computer science have become irrelevant to
the IETF and, at the risk of invoking another conversation, the
Humpty Dumpty philological system has taken over entirely.

(1) The community approved RFCs 2141 and 3406 as a Proposed
Standardsd and BCP, respectively.  RFC 1737 provides useful
information and context, but it is an Informational document and
has never been seriously claimed to represent community
consensus.   I note that such a document would not be allowed to
have "Requirements" in its title today.  It is interesting the
the title of RFC 1736 includes "Recommendations", not
"Requirements".

(2) RFC 3986 is not identified as updating, altering, or
restricting any of 2141 or 3406, nor, for that matter, 1737.
RFC 2396 is not identified as changing any of those
specifications either.  The sentences in Section 1.1.3 of RFC
3986 (and Section 1.2 of 1737 read as an explanatory and
tutorial "overview" not normative requirements.

(3) RFC 3986 Section 1.1.3 indicates that "A URI can be further
classified as a locator, a name, or both".   While that text
reinforces the (IMO, unfortunate) confusion between generic
name-class URIs and the "urn" scheme, there appears to be
nothing in 3986 (in that section or otherwise) that allows, much
less requires, one scheme to constrain another, either within
classes or across them.  It would be as unreasonable to claim
that the definition of the "urn" scheme imposes a constraint on
a hypothetical member of the "both" class at is would be to
claim that the definition of the "xmpp" or "sip" schemes
constrain the "http" scheme.

(4) While the title and abstract of 3986 appear very clear that
it, and its normative requirements, are about syntax, the
document also contains a great deal of explanatory, descriptive,
and other semantic information.  It is possible to separate
those things from the syntax, if necessary by modifying 3986
which does not (and could not) contain provisions that write its
provisions into stone with no possibility of modification.

At least so far, the IETF has not given up on the importance of
good sense and deployment experience and practices (sometimes
included under "running code") in interpreting written standards
and practices, including "BCP" documents that lay out procedures
or hopes for the future rather than documenting practices
already in widespread use.  When a standards-track document
exists, specifies things that are widely deployed and have been
for years, is associated with values in a registry, and clearly
anticipates certain future extensions, a claim that a later set
of documents prevent those extensions (or bar a designated
expert from approving IANA's installing an updated
registration), that would be a serious issue, requiring wide and
careful community review of the tradeoffs involved.  

I do not believe that either draft-ietf-appsawg-uri-scheme-reg
or RFC 3986 impose such requirements on the "urn" scheme.
Therefore, I do not believe there is a substantive problem with
draft-ietf-appsawg-uri-scheme-reg even though (as with most
other IETF documents) we could, if so inclined, quibble over
exact choices of words for months or years.  I am not so
inclined if it can be avoided.   

On the other hand, if claims are made that
draft-ietf-appsawg-uri-scheme-reg either adds constraints to
those that are clearly present in RFC 3986 or reinterprets (or
"clarifies") text in 3986 to impose stronger or different
requirements than are present there, especially on URI schemes
that existed long before 3986 and that were not explicitly
modified by it (or registration of updates to them), then there
are, IMO, serious problems with either the interpretation, of
this new specification, or both and fairness and reasonableness
require that they be sorted out now.

Finally, an observation: It has been said many times that the
primary purpose of  draft-ietf-appsawg-uri-scheme-reg is to make
registrations easier, especially for schemes that are, or are
reasonably expected to become, widely deployed and significant
to the Internet.    It seems ironic, perhaps even perverse, that
a document that is justified on that basis is being held up
because of claims that it will, as soon as approved, impose more
stringent requirements on one or more URI schemes that are
already broadly deployed and demonstrably important to the
community.

> (All of this leaves me wondering if it would be helpful to
> state that explicitly in the registration document, but at
> this stage in the process I'm reluctant to introduce
> suggestions for shadow-dodging changes.)

See above.

best,
   john

---

From: Keith Moore <[email-masked]>
Date: Sat, 18 Apr 2015 14:58:16 -0400

I might comment on the rest of John's note later, but for now I'll just 
limit my response to this portion:

> the title of RFC 1736 includes "Recommendations", not

RFC 1737 was approved at a time that BCPs didn't yet exist.   Since it's 
not a protocol document, it wouldn't have been suitable for 
standards-track, and there wasn't any other way that the IESG could 
indicate community approval.   Informational was the only label that 
could be given to it.   So one can't really derive much significance 
from the lack of a BCP label.

It might not represent community-wide consensus at the time.  But to the 
best of my recollection it does represent a consensus of the URN WG.

Keith

---

From: Larry Masinter <[email-masked]>
Date: Sat, 18 Apr 2015 20:42:59 +0000

BCP 35 specifies the process and guidelines for URI schemes, and draft-ietf-appsawg-uri-scheme-reg updates BCP 35, and is effective as soon as it is published.

As far as a prior ruling of non-applicability  to URNs —  what OTHER guidelines or processes would apply to updates of a previously registered scheme? 
But these are GUIDELINES. There is no formal or IANA-enforced requirements or Expert Reviewer override.  IETF consensus on a URN document that directs IANA to change the “urn:” scheme registration will cause the registration to change. Explaining why you’re not following BCP 35 might be helpful in getting IETF consensus, but there is no specifics on what constitutes an adequate justification. 

If there were specific suggestions or comments on how to make BCP 35 into better “best current practice” for the IANA URI scheme, we should fix it. 

To calibrate, I think lifetime of this edition of BCP 35 will be short. It may well be that a more wholesale set of changes of specification and model of URL schemes are needed.

The use of IANA to enumerate schemes is in question, for "the web”;  I think it doesn’t really mesh well with a world with ‘registerProtocolHandler’, which seems to
assume a more dynamic matching of scheme to handler (no IANA involvement at all).

So I think it’s time to reexamine the broader picture. Are “web” and “non-web” and “URN” URL/URI/URNs different things, or are we going to try to keep them together? The tension between having a single protocol element which is used for multiple purposes is in conflict with the requirements of optimum adaptation for specific categories of applications.

https://tools.ietf.org/html/draft-ruby-url-problem-01

in the meanwhile, let’s get this update out.

Larry
—
http://larry.masinter.net

---

From: Barry Leiba <[email-masked]>
Date: Sat, 18 Apr 2015 22:14:40 -0400

I think what Larry says here is exactly right -- this, in particular:

> But these are GUIDELINES. There is no formal or IANA-enforced
> requirements or Expert Reviewer override.  IETF consensus on a
> URN document that directs IANA to change the "urn:" scheme
> registration will cause the registration to change. Explaining why
> you're not following BCP 35 might be helpful in getting IETF
> consensus, but there is no specifics on what constitutes an
> adequate justification.

I'm happy to consider that this is the last that needs to be said on
this topic with respect to this document.  Thanks, Larry.

Barry