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

From: [email-masked]
Date: Fri, 27 Mar 2015 09:33:31 -0700

A new version (-05) has been submitted for draft-ietf-appsawg-uri-scheme-reg:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-uri-scheme-reg-05.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-uri-scheme-reg-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.

---

From: Dave Thaler <[email-masked]>
Date: Fri, 27 Mar 2015 19:26:58 +0000

Hi Barry, 

Larry, Tony, Alexey, and I met yesterday to go over proposed resolutions to the feedback received.
I've attempted to make changes per what we've discussed, though my co-authors and doc shepherd
need to check, and if I messed up anything, I can spin another rev early next week if needed.

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.

Dave

-----Original Message-----
From: apps-discuss [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, March 27, 2015 11:34 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.

_______________________________________________
apps-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 29 Mar 2015 15:05:33 +0100

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?

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?

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 30 Mar 2015 20:13:00 +0900

> Do people agree that this is problematic?

I agree that it would be problematic if the expert reviewer could block. 
However, my understanding is that IETF consensus (not WG consensus) 
would be stronger than expert review, and would win in the end if there 
was really a conflict that couldn't be resolved otherwise. Isn't that 
the case?

My understanding is based on just the general observation that both the 
Expert Reviewer and IANA (for the registry in question) serve at the 
pleasure of the IETF and the IESG (in particular, at the pleasure of the 
AD).

Note that 7.2.,  Registration Procedures, also contains the following:

    6.  In the case of a Permanent registration request, the Designated
        Expert may:

        *  Accept the specification of the scheme for permanent
           registration.

        *  Suggest provisional registration instead.

        *  Request IETF review and IESG approval; in the meanwhile,
           suggest provisional registration.

        *  Request additional review or discussion, as necessary.

This essentially says that the expert reviewer only can delay things (by 
suggesting provisional registration or additional review or discussion), 
not completely refuse permanent registration.

Regards,   Martin.