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

[Dave Thaler <[e-mail]>]

> -----Original Message-----
> From: Alexey Melnikov [mailto:[e-mail]]
> Sent: Sunday, March 29, 2015 7:06 AM
> To: Barry Leiba
> Cc: Dave Thaler; [e-mail]
> Subject: Re: FW: [apps-discuss] New Version Notification - draft-ietf-appsawg-
> uri-scheme-reg-05.txt
> 
> 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:
> 
> 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.
> 
> Do people agree that this is 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