Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt

From: Alexey Melnikov <[email-masked]>
Date: Wed, 01 Apr 2015 20:40:44 +0100

On 29/03/2015 20:59, John C Klensin wrote:
> --On Sunday, March 29, 2015 15:05 +0100 Alexey Melnikov
> <[email-masked]> wrote:
>
>> On 27/03/2015 19:29, Barry Leiba wrote:
>>>> I will send email responses to the feedback received with
>>>> what we did. I may not get those out today though. But I
>>>> think the doc should be ready for the IESG telechat.
>>> Thanks.  I've issued the ballot; I'll wait to change the
>>> state until I hear that your co-authors & shepherd are OK
>>> with it.
>> This is almost perfect :-).
>>
>> A couple of comments:
>> ...
>> Here is a real world example of a problem with this text. SIDR
>> WG decided to use rsync protocol, they needed to use rsync
>> URIs. rsync URIs are currently provisional, defined in an
>> Informational RFC.  So this text is basically saying that
>> under the new rule the registration have to be upgraded to
>> Permanent, allowing the expert reviewer (no disrespect to
>> Graham or his future replacement) to be a person that blocks
>> consensus of a WG to use a particular technology. I find this
>> to be problematic.
>>
>> Do people agree that this is problematic?
> Yes.
>
> At the risk of tossing a spanner toward the works, one more
> issue that seems to me very significant:
>
> Larry Masinter has raised several issues in the URNBIS WG in
> which he claims that draft-ietf-appsawg-uri-scheme-reg
> constrains what that WG is proposing to do with URNs [1].  I
> also believe that some of his comments mix up registration of
> schemes (e.g., "urn:") with registrations of URN namespaces and
> NIDs  I think those issues need to be considered in that WG.
> However, procedurally, it seems to me that either:
John, from looking at the list of changes since RFC 4395 in 
draft-ietf-appsawg-uri-scheme-reg, I don't see anything obvious that 
would break URNs.

But reading [1], here is my personal opinion:

1. Use of “/“ - I agree with Larry that this should be fixed in the 
draft-ietf-urnbis-rfc2141bis-urn. URNs are either hierarchical or they 
are not. They can't be "sort of hierarchical".
2. Use of “#” - I think this needs to be discussed. I agree that there 
is an issue, but I am not sure about solutions yet.
3. Update of formal namespaces with ‘Expert Review’ - I agree with you 
that what draft-ietf-appsawg-uri-scheme-reg says has no impact on URN 
namespaces. However, I agree with Larry that a similar solution should 
(SHOULD ;-)) be used for URNs.

The issue #1 is not really new to draft-ietf-appsawg-uri-scheme-reg. I 
am not sure about #2. If it is, it also need to be listed in the 
"changes since" section.

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

---

From: Dave Thaler <[email-masked]>
Date: Tue, 7 Apr 2015 23:56:37 +0000

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Sunday, March 29, 2015 7:06 AM
> To: Barry Leiba
> Cc: Dave Thaler; [email-masked]
> Subject: Re: FW: [apps-discuss] New Version Notification - draft-ietf-appsawg-
> uri-scheme-reg-05.txt
> 
> >> I will send email responses to the feedback received with what we did.
> >> I may not get those out today though. But I think the doc should be
> >> ready for the IESG telechat.
> > Thanks.  I've issued the ballot; I'll wait to change the state until I
> > hear that your co-authors & shepherd are OK with it.
> 1) The last paragraph in Section 3.6  (Internationalization and Character
> Encoding)  now reads (the last sentence is new):
> 
>     All percent-encoded variants are automatically included by definition
>     for any character given in an IRI production.  This means that if you
>     want to restrict the URI percent-encoded forms in some way, you must
>     restrict the Unicode forms that would lead to them.  In most cases,
>     it is advisable to define the actual characters allowed in an IRI
>     production, to allow the 'pct-encoded' definition from Section 2.1 of
>     [RFC3986] at the same places, and to add prose that limits percent-
>     escapes to those that can be created by converting valid character
>     sequences to percent-encoding via UTF-8.
> 
> 
> The last part of the sentence doesn't read well (and I can't understand exactly
> what is it trying to do):
> 
>     and to add prose that limits percent-
>     escapes to those that can be created by converting valid UTF-8
>     character sequences to their percent-encoding.
> 
> 
> Dave, is this what you intended?

Yes

> 2) Regarding my earlier disagreement about text suggested by Graham:
> 
> 3.  Requirements for Permanent Scheme Definitions
> 
>   This section gives considerations for new schemes. Meeting these
>   guidelines is REQUIRED for permanent scheme registration.
>   Permanent status is appropriate for, but not limited to,
>   use in standards. For URI schemes defined or normatively
>   referenced by IETF Standards-Track documents, Permanent registration
> status is REQUIRED.
> 
> He added "or normatively referenced" which now appears in the draft.
> 
> Here is a real world example of a problem with this text. SIDR WG decided to
> use rsync protocol, they needed to use rsync URIs. rsync URIs are currently
> provisional, defined in an Informational RFC.  So this text is basically saying
> that under the new rule the registration have to be upgraded to Permanent,
> allowing the expert reviewer (no disrespect to Graham or his future
> replacement) to be a person that blocks consensus of a WG to use a
> particular technology. I find this to be problematic.
> 

This was basically discussed in the thread month ago.  See
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg14045.html 
for Barry's message in that thread, which I agree with.   That thread is where
it looked like there was consensus that the intent was as currently worded.

Specifically, Barry's point was:
> without some change like that, one can simply pull
> a URI scheme definition out of a Standards Track document, post it on
> a web site, get a provisional registration for it, and use it in the
> Standards Track document... making this requirement fairly pointless.

We already got consensus (including advice from the AD during the WG meeting)
to empower the Expert Reviewer more and lessen the load on the IESG.
I think the current text is also in keeping with that consensus.  If a blockage
happens, it can be escalated to the IESG, which also controls who the Expert
Reviewer is, so the IESG always has a way of overriding the Expert anyway.
Since that escape hatch is there, I believe the current text is correct as is,
and reflects consensus both in the meeting and on the list.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Wed, 8 Apr 2015 00:09:28 +0000

John C Klensin wrote:
> Larry Masinter has raised several issues in the URNBIS WG in which he claims
> that draft-ietf-appsawg-uri-scheme-reg constrains what that WG is proposing
> to do with URNs [1].  I also believe that some of his comments mix up
> registration of schemes (e.g., "urn:") with registrations of URN namespaces
> and NIDs  I think those issues need to be considered in that WG.
> (1) Existing registrations are existing registrations and any updates to them
> are grandfathered, i.e., whatever draft-ietf-appsawg-uri-scheme-reg says is not
> applicable to the original or updated registration of any URI scheme
> registered or deployed before it is approved and published.  That obviously
> includes the revised URN registration contemplated by draft-ietf-urnbis-
> rfc2141bis-urn.

It's certainly not applicable to the original registration before the new procedure
is published.   I believe it ought to apply to updates though the IESG and/or
the Expert Reviewer should take into account the existing registration and
act accordingly.   An example of why I think it should apply to updates is that
say an actual owner wants to update a registration of a Provisional scheme
that I or Alexey registered as a third-party scheme, doing so should not
require an Expert Review, where the old process did.

The new doc lowers the bar, it doesn't raise it.
To my knowledge there's no MUST in it that's more strict than RFC 4395, together
with RFC 3986 and 3987, was intended to be.

The issues with URN are about where one can argue that it doesn't/didn't meet
one or more of RFC 4395, 3986, or 3987.   The new doc doesn't change it except
to make it clearer, and to make some requirements (i.e. for Provisional) weaker.

> (2) We have a mess on our hands in which not only do the mandates of
> different WGs overlap but in which an area WG that is not noted for very
> intense reviews can constrain and override the work of more topic-focused
> (and, therefore, presumably more expert on their own topics) WGs and other
> efforts.  This is particularly problematic in the case of URIs, where parallel
> (and not entirely consistent) work is going on to further develop specific URI
> schemes (URNs being only one such example) and groups outside the IETF
> (including WHATWG and W3C groups) with coordination processes that are
> still being negotiated and in groups that are heavily dependent on URIs and
> URI handling (certainly including HTTPbis).
> 
> If it is applicable to existing registrations and ongoing work in other WGs, this
> spec is even more problematic because it is heavily dependent on details of
> RFC 3986, a specification whose exact meaning, implications, and
> consequences continue to be debated and which is a candidate for
> preemption or replacement by those other bodies.
> 
> I suggest that any IESG action on
> draft-ietf-appsawg-uri-scheme-reg be deferred until which of the above
> principles applies can be clarified (and clarified in the
> document) and, if the second option is chosen, that formal reviews and
> impact assessments be sought from all active WGs that are involved with or
> use URIs as well as from W3C.

In my opinion, delaying publication of draft-ietf-appsawg-uri-scheme-reg
would be harmful since it keeps the bar high and disincents people from registering
at all.   I believe the issues you're worried about should be dealt with separately
from draft-ietf-appsawg-uri-scheme-reg.   If it turns out that some change is
needed to draft-ietf-appsawg-uri-scheme-reg later, we can always rev then.
But we should not hold up lowering the bar for Provisional until some indefinite
future period.

Dave

> Sorry to be raising this so late in the process, but it never occurred to me that
> anyone would claim that draft-ietf-appsawg-uri-scheme-reg constrained other
> IETF WGs, standards-track updates to existing registrations that were made as
> the result of standards actions, etc.  Since that claim has now been made, and
> made by one of the authors of the new draft who presumably understands
> the intent, a "wait a minute"
> response seems necessary.
> 
>      john
> 
> 
> [1]