Re: [apps-discuss] New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt

[Graham Klyne <[e-mail]>]

Hi,

Broadly, I concur or do not disagree with Mark's comments.  A few additional 
thoughts interleaved.

On 17/02/2014 06:12, Mark Nottingham wrote:
> Hi Dave,
>
> I took a look through, and the draft looks very good; quite readable.
>
> A few notes I scratched down as I went through, FWIW:
>
> * Introduction - "discourage use of the same scheme name for different purposes." This is a bit ambiguous; e.g., I use http:// for the purposes of checking the weather and my bank balance, and that's OK. Suggest: "discourage handling of a scheme by in conflicting ways."
>
> * Introduction (and throughout) - there are a number of lowercase "should" and "may"s in the document; some people might complain.
>
> * Demonstratable... - s/demonstratable/demonstrable/
>
> * Demonstratable - "...some parts of URI processing may be scheme-dependent." I think this needs to be stronger; at least "...are often scheme-dependent."
>
> * CREF1 - LGTM.
>
> * Syntactic Compatibility - "Schemes that are not intended for use with relative URIs SHOULD avoid use of the forward slash "/" character, which is used for hierarchical delimiters, and the complete path segments "." and ".." (dot-segments).  If they avoid use of "/", how do you tell what delimits dot-segments from other stuff?
>
> * Syntactic Compatibility - "...the first part of a URI is not an artistic indicator..."  I'd drop "artistic".
>
> * Syntactic Compatibility - "Schemes that do not contain a conformant hierarchical structure in their <scheme-specific-part> SHOULD NOT use double slashes following the <scheme:> string."  Why is this not a MUST NOT?
>
> * Well-Defined - "While URIs may or may not be defined as locators in practice, a scheme definition itself MUST be clear..."  Does this really deserve to be a MUST? When advice is given about what to document elsewhere in the spec, it always seems to be a SHOULD.
>
> * Well-Defined - "In particular, the mapping SHOULD describe the mechanisms for encoding binary or character strings within valid character sequences in a URI."  I feel like this ought to be more clearly qualified to cases where such content is valid for the application; some might read this as requiring a mapping for binary in all schemes.
>
> * Definition of Operations - HTTP calls them "methods", and this should be noted here to avoid confusing people (we saw it recently).
>
> * Definition of Operations - I'd like to see us encourage (but probably not require) schemes to define a *default* operation for locators; the AWWW calls this "dereferencing" <http://www.w3.org/TR/webarch/#dereference-uri> and it would be nice to align the worldviews between the W3C and IETF here. It would also be good if we encouraged such default methods to be "safe" -- that is, not having surprising or undesired side effects, from the client's standpoint.

This makes sense for many schemes, but not so much for "pure" identifier schemes 
like urn:, etc.  I argued for something like this for the acct: scheme, but in 
the end did not persuade.

>
> * Scheme Name Considerations - There's a shift in use of language in this section in the two paragraphs starting with "Avoid..." -- it's direct, first-person advice, whereas the rest of the spec is more third-person.
>
> * Scheme Name Considerations - I'm very much against "private" / organisationally scoped registrations -- is the idea that someone can then make up new URI schemes without registering them? This seems counter to the purposes of having URIs, as per the AWWW.
>

+1

(I already commented on this in another message, but I'll emphasize my 
concurrence here.)

> * CREF2 - The HTML5 folks have spec'd (not clear if they've implemented) web+, so we should at least talk about it. To me, the problem is that if somebody comes along and does something like email+, which one wins -- i.e. do I now have to handle both email+web+http:// and web+email+http:// as equivalent? Bleurgh.
>

FWIW, I'd say web+foo and email+foo are simply different schemes.  There's no 
sense in which one can "win".

> * CREF3 - As per above, I think that allowing domain-based URI schemes is a Bad Idea. What's the use case?
>
> * Guidelines for Provisional URI Scheme Registration - The first paragraph indicates that provisional is for "private" schemes. I think we need to have a discussion about that in the WG (perhaps in a separate thread), because AFAICT provisional is NOT being used that way; rather, it's being used to reserve namespace for parties that can't be bothered doing full registration. That's not to say that there's something wrong with that; as the draft points out, one motivation is to make registration easier; it's just that we should be honest about why we have provisional - I'd rather not encourage private URI use at all (but keep provisional).
>
> * Registration Procedures - I'd be much more comfortable if there were references in this section to the previous requirements; people often just skip to this section in this kind of RFC, oblivious to the carefully prepared requirements and arguments above. In an ideal world, I'd restructure the draft so that the whole thing read like a flow chart, but I'm not going to ask the WG to do that :)
>
> * Registration Procedures - "Unless Expert Review has explicitly rejected the registration request within two weeks, IANA should automatically add the registration to the registry as 'provisional."  I'm a bit uncomfortable with this; if the Experts aren't on the ball, get sick, go on holiday, etc., we can end up with some surprising results. Can we just raise an exception to the ADs or something?
>

I think the idea was that a non-responsive expert would not block the process. 
In practice, to date, IANA keep prodding until they get a response (I sometimes 
benefit from a reminder, but I don't think I've every completely failed to 
respond in 2 weeks).

#g
--


> That's all I've got. Thanks again,
>
>
> On 15 Feb 2014, at 9:21 am, Dave Thaler <[e-mail]> wrote:
>
>> This draft replaces draft-ietf-iri-4395bis-irireg-04. Since the IRI
>> WG closed, we've gone back to it being an individual submission.
>> This version addresses some of the issues raised on -04 (see
>> draft-thaler-uri-scheme-reg-ps-01 and the discussion at last IETF) as
>> noted below. There are still a number of open issues for which, with
>> the permission and help of the appsawg chairs, I have filed issue
>> tracker tickets to track.
>>
>> I have not filed tickets for things already addressed in this version.
>> These are enumerated below, and if there are disagreements on any
>> then we can file a ticket for it.
>>
>> 1) The IRI WG previously agreed that the fragment component is not
>> scheme-specific, and that the doc should be updated to clarify that
>> a scheme definition should only define the scheme-specific part.
>> This is now done at end of section 1.
>>
>> 2) Since the IRI WG was closed, I reverted most of the IRI-specific
>> changes from RFC 4395 that were in draft-ietf-iri-4395bis-irireg-04.
>> I left in text clarifying that a URI scheme name and an IRI scheme
>> name were the same and hence there aren't separate registries, since
>> apparently that was a common question on RFC 4395.
>>
>> 3) As noted in draft-thaler-uri-scheme-reg-ps and in my presentation
>> at last IETF, the IRI WG previously agreed that the 4-week mailing
>> list review was optional for Provisional. RFC 4395 was ambiguous as
>> to optional vs mandatory. Updated text in section 7.2 to make it
>> explicit that it is only mandatory for Permanent.
>>
>> 4) As noted in draft-thaler-uri-scheme-reg-ps and in my presentation
>> at last IETF, RFC 4395's convention for private namespaces (i.e.,
>> converting "." to "-" in scheme names based on a domain name)
>> causes conflicts. Updated example to use "." instead of "-" to
>> reduce collisions. And open ticket #17 covers the rest of the
>> conflict problem.
>>
>> 5) Combined the Permanent, Provisional, and Historical URI Scheme
>> sub-registries into one URI Scheme registry with a status column.
>> This is done to make it easier to prevent duplicates and see
>> existing conventions, as well as to support the "Pending Review"
>> temporary state added in draft-ietf-iri-4395bis-irireg.
>>
>> -Dave
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Friday, February 14, 2014 12:13 PM
>> To: Larry Masinter; Dave Thaler; Ted Hardie; Dave Thaler; Larry Masinter; Ted Hardie; Tony Hansen; Tony Hansen
>> Subject: New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt
>>
>>
>> A new version of I-D, draft-thaler-appsawg-uri-scheme-reg-00.txt
>> has been successfully submitted by Dave Thaler and posted to the IETF repository.
>>
>> Name:		draft-thaler-appsawg-uri-scheme-reg
>> Revision:	00
>> Title:		Guidelines and Registration Procedures for New URI Schemes
>> Document date:	2014-02-14
>> Group:		Individual Submission
>> Pages:		18
>> URL:            http://www.ietf.org/internet-drafts/draft-thaler-appsawg-uri-scheme-reg-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-thaler-appsawg-uri-scheme-reg/
>> Htmlized:       http://tools.ietf.org/html/draft-thaler-appsawg-uri-scheme-reg-00
>>
>>
>> Abstract:
>>    This document updates the guidelines and recommendations, as well as
>>    the IANA registration processes, for the definition of Uniform
>>    Resource Identifier (URI) schemes.  It obsoletes RFC 4395.
>>
>>
>>
>>
>> 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.
>>
>> The IETF Secretariat
>>
>> _______________________________________________
>> apps-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>