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

[John C Klensin <[e-mail]>]

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

>> 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.
> 
> 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.

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