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

From: Dave Thaler <[email-masked]>
Date: Sat, 11 Oct 2014 00:30:42 +0000

Graham Klyne wrote:
> 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) [...]
> 
> 
> 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.

Agreed, and I believe (a) is already consistent with existing WG consensus,
so it is purely editorial in my view.

Accepted proposed text to replace the REQUIRED.  And there were uses of
SHOULD in the text for each of the criteria.  I changed 'SHOULD' to 'should'
in each case, since they're all under the intro text Graham quotes.

> 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)?

I don't think it's a good idea to use up WG effort to design a process for
something that's never been a problem and we hope never will be, as long as
it's not catastrophic if it does occur. For URI schemes, it's not catastrophic
and there are already other recourses such as reclassifying as Historic or
adding info to the Notes column.  And as no one else brought it up and
Graham only asks it as a question, I'll treat this as addressed unless
someone raises it as a blocking issue during IETF Last Call.

> ...
> 
> 
> 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.

Done, with 
s/should be/SHOULD be/

> # 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.

Done as suggested.

> # 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.

Agree with the problem, though the text suggested above just moves the
problem around since that text doesn't match what section 5 of RFC 6335
actually talks about.  Reworded instead as:

    A scheme name is not a "protocol" although, like a
    service name as defined in section 5 of [RFC6335],
    it often identifies a particular protocol or application.
    If a scheme name has a one-to-one correspondence with
    a service name, then the names SHOULD be the same.

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

Roy Fielding mentioned the same thing in his review.

Yes, it was to be removed at end of WGLC as the cref implied.
I have now done so in -03 and will close the two relevant tickets
(#17 for this one).

-Dave