Subject: [apps-discuss] WGLC on draft-ietf-appsawg-uri-scheme-reg

From: Alexey Melnikov <[email-masked]>
Date: Thu, 28 Aug 2014 19:25:17 +0100

This message officially starts the APPSAWG Last Call for the following 
document:
     Guidelines and Registration Procedures for New URI Schemes
http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/

The Working Group Last Call for this document starts today, on Thursday, 
28th of August and will end on Friday, 19th of September. This is about 
3 weeks to accommodate for holiday season and impact this document can 
have on IETF and other SDOs.

Please send any comments to the apps-discuss mailing list or directly to 
the chairs.  Even if you reviewed this document
and found no issues then please let the chairs know.

Thank you,
Alexey Melnikov, as an APPSAWG co-chair

---

From: Graham Klyne <[email-masked]>
Date: Fri, 29 Aug 2014 10:48:08 +0100

On 28/08/2014 19:25, Alexey Melnikov wrote:
> This message officially starts the APPSAWG Last Call for the following document:

It's been a while since I looked at this.  Generally, I think it looks very 
good.  Coming to this with relatively fresh eyes, I have some new comments.

...

I have one possibly substantive comment:

Section 4.1 sets out normative requirements on provisional registrations, mostly 
SHOULD, but some REQUIRED.  Yet section 7.1 removes the requirement for any 
review (which I support).  Thus, while I'm all for encouraging that various 
desiderata in section 4.1 are satisfied, I'm not sure if it works for these be 
be normative in a specification that may be not reviewed.  My thoughts are to 
either:

(a) tone down the normative language in section 4.1, while leaving everything 
strongly encouraged.  E.g.

Current:

     For a provisional registration, the following are REQUIRED:

Propose:

     For a provisional registration, submitters are strongly encouraged to
     ensure their proposal satisfies the following criteria:

(b) introduce some wording (e.g. in section 7.1) about the possibility of 
removal of a registration that is subsequently found to not conform to the 
normative requirements.

On balance, as the purpose of provisional registration is to facilitate access 
to even rudimentary information about proposed and in-use schemes, I favour 
option (a) or similar.

Related to this.  It's never been a problem to date, but should there be some 
defined possibility for frivolous or disruptive registrations to be removed 
(e.g. at request of DE)?

...

The following comments are mostly editorial, and don't substantively affect the 
spec.

# 3.4.  Definition of Operations

Final paragraph (dereferencing).  I think the spec should say something about 
dereferencing a URI being "safe", in the sense of 
http://www.w3.org/TR/2004/REC-webarch-20041215/#safe-interaction

E.g., include something like this:

     The default invocation, or dereferencing, of a URI should be "safe"
     (in the sense described by [W3CWebArch] section 3.4);  i.e. an agent
     performing such an interaction should not incur any additional
     obligations by doing so.

# 3.7.  Clear Security Considerations

Current:

     The definition of an individual scheme should note which of these apply
     to the specified scheme.

Suggest:

     The definition of an individual scheme should note which of these apply
     to the specified scheme, in addition to any more scheme-specific concerns.

# 3.8.  Scheme Name Considerations

Para 5.  The text introduces protocols and applications, then describes a 
requirement in terms of services.  I find this reads oddly.

Current:

     If a scheme name has a one-to-one correspondence with a service name
     (see section 5 of [RFC6335]), then the names SHOULD be the same.

Suggest:

     If a scheme name has a one-to-one correspondence with a protocol or
     application name (see section 5 of [RFC6335]), then the names SHOULD
     be the same.

Final para:  I note there is still a problem reference [[CREF1...]] in this 
last-call document.

...

That's all I have for you.

#g