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

From: Dave Thaler <[email-masked]>
Date: Sat, 29 Mar 2014 01:13:35 +0000

Mark Nottingham wrote: 
> * 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."

Existing text is straight from RFC 4395.   How about
"discourage use of the same scheme name for different mechanisms"
?  (I couldn't think of a better word than mechanisms.)

Both HTTP purposes you mention use the same mechanism (the HTTP
protocol) but I don't want to use protocol since a scheme name doesn't
require the existence of a protocol.

> * Introduction (and throughout) - there are a number of lowercase "should" and
> "may"s in the document; some people might complain.

These are all straight from RFC 4395.   A couple are trivial to replace with other words.
Otherwise, if I think it's unambiguous already, I'll leave it to see if anyone
actually complains.

> * Demonstratable... - s/demonstratable/demonstrable/

Done in my local copy (previously straight from RFC 4395).

> * Demonstratable - "...some parts of URI processing may be scheme-
> dependent." I think this needs to be stronger; at least "...are often scheme-
> dependent."

Agreed and accepted.

> * CREF1 - LGTM.

Thanks, removing CREF1.

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

This is straight from RFC 4395.   It says they SHOULD avoid both "/" and dot-segments.
So if you avoid dot-segments, you don't need to tell what delimits them from other stuff.

> * Syntactic Compatibility - "...the first part of a URI is not an artistic indicator..."
> I'd drop "artistic".

Straight from RFC 4395, but accepted.

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

The authors of RFC 4395 which had this statement, should answer that...
Tony, Ted, or Larry?  I suspect the answer is because it doesn't seem to cause
any interoperability issues if it's violated, and indeed some heuristics for
detecting URIs in plaintext might actually work better if it's violated.

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

Not sure if the authors of RFC 4395 have an answer but my view is...
I don't know how you can call a scheme definition a "scheme definition" if it
does not actually define whether it's a locator or not.

Also the "Clear Security Considerations" section (same as in RFC 4395) also has a
MUST so this isn't the only such occurrence.

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

Since I think it's already clearer in section 3.6, so how about this...

OLD:
   In particular, the mapping SHOULD
   describe the mechanisms for encoding binary or character strings
   within valid character sequences in a URI (see Section 3.6 for
   guidelines).

NEW:
   See Section 3.6 for guidelines for encoding binary or character strings
   within valid character sequences in a URI.
 
> * Definition of Operations - HTTP calls them "methods", and this should be
> noted here to avoid confusing people (we saw it recently).

OLD:
   A model for this is HTTP; an HTTP resource can be operated on by GET,
   POST, PUT, and a number of other operations available through the
   HTTP protocol.

NEW:
   A model for this is HTTP methods; an HTTP resource can be operated on by GET,
   POST, PUT, and a number of other methods available through the
   HTTP protocol.

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

Agreed, though I'm not sure what to say about "safe" (text suggestions welcome).

Added this sentence:
   Scheme definitions SHOULD define a "default" operation for when a URI is
   invoked (or "dereferenced") by an application.

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

Yep.  This was in RFC 4395 but will change for consistency.

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

Yes I believe that was the idea, and I don't believe it's counter to the purposes of
having URIs.  Indeed we've learned by observation of reality that people will
do that regardless of what we say.   So I think the idea was to allow self-generated
unregistered ones, based on your domain name, so if they leak then at least
you can be tracked down and interrogated :)
 
> * 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.

This is part of ticket #16 which the WG discussed at IETF.
The rough consensus in the room was not to allow this, hence removed cref2
and closed the ticket.

> * CREF3 - As per above, I think that allowing domain-based URI schemes is a
> Bad Idea. What's the use case?

Was already allowed in RFC 4395.  See response above.
I don't want to disallow existing things that are already legal unless there's strong
consensus to do so, since that won't cause people to use unregistered schemes,
removing that guidance would just cause people to use unregistered schemes
that you can't track down to someone, which is IMO a worse state.

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

No, it doesn't indicate the provisional is for "private" schemes.  It (same as
RFC 4395) says it's for schemes that are NOT private.  Here's the text:

   Provisional registration can be used for schemes that are not part of
   any standard, but that are intended for use (or observed to be in
   use) outside a private environment within a single organization.

The key word is "outside" a private environment.   It sounds like you read it
(as "inside") opposite to how it was intended.  I changed "outside" to
"that is not limited to" in the hopes that's clearer.

> * 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 :)

I can't tell if you're suggesting something actionable above or not.
If so, can you give an example of what you'd like to see?

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

The above sentence will go away in the next rev since there was general support
for changing Provisional to FCFS.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Sat, 29 Mar 2014 01:51:39 +0000

Responding in detail as I'm editing the document to address...

Graham Klyne wrote:
> I'm responding with a perspective of being the current designated IANA
> reviewer.
>   Broadly, I'm supportive of the changes proposed, and in particular to lower
> the perceived barrier to provisional registration of schemes.
> 
> ...
> 
> Section 3: "For IETF Standards-Track documents, Permanent registration status
> is REQUIRED."  -- I can guess at what this is trying to say, but I think it's not
> clear (and I wonder if it needs to be saif at all).

It seems clear to me, can you elaborate?

I think it does need to be said.   When the IETF does a standards-track document,
the authors/WG should be looking at the Permanent registration requirements,
not the lower bar.

> ...
> 
> Section 3.3 ("well defined").  One of the first questions I ask myself when
> reviewing a URI scheme proposal is: "What kinds of thing do URIs in this
> scheme identify, or how do I find out?".  I'd like to see all scheme registrations
> providing a clear answer for this.

Agreed.  (I think Mark argued for dropping the "MUST be clear as to how it is 
expected to function" to a SHOULD, but I agree this should stay a MUST for
Permanent registrations.)
 
> One of the problems I have sometimes experienced in reviewing URI scheme
> registration submissions is understanding what the corresponding scheme is
> intended to identify.  If it is a locator, then it's usually fairly clear.  But some
> schemes I've seen - particularly where used as particular identifiers within
> other protocols - have been less clear (in their original submissions).
> Recent(ish) examples that come to mind are acct:, turn: and stun: (not
> criticizing them, just trying to give examples of things that are not always
> immediately clear).
> 
> I think the text "Schemes that are not intended to be used as locators SHOULD
> describe how the resource identified can be determined or accessed by
> software that obtains a URI of that scheme." goes some way to this, but that
> was present in the previous draft and didn't always get noticed.  Also, there is
> not always a mechanism that is available to software (e.g. urn":).  I'm
> wondering if this can be beefed up a bit... e.g. to lead with something like:
> 
> "URI scheme specifications should be clear about the kind of resource that they
> may identify, or the means (technical or non-technical) by which URIs are
> related to the resources they identify"
>
> My text could surely be improved.  

Personally, I find that less clear than the current sentence, not sure what others think.
I don't have a better suggestion right now.

> The first part of this would apply to a
> scheme like "acct:" saying that an acct: URI identifies a user account in some
> domain or system (**); the latter would apply to locator schemes like http:, or
> identifier schemes like urn: where there is a defined administrative delegation
> structure.
> 
> <aside>
> (**) for background, the acct: scheme was defined as part of the WebFinger
> work, but acct: URIs are not specifically tied to or defined by the WebFinger
> protocol.
> </aside>
> 
> In making this comment, I also note there is some slight overlap with material
> covered in section 3.4.

Perhaps.  Not sure if there's anything actionable there though.  Better to have
slight overlap than a slight gap, I guess.

> 
> ...
> 
> Section 3.8:
> 
> Re:  "[[CREF2: Open Issue: Should we define a mechanism to register a scheme
> prefix ("web+", "ms-", etc.)?  --DT]]"
> 
> I think not.
> 
> I've not come across any great need for this, and I think it might even
> encourage scheme proliferation in conflict with the exhortations in section 3.1
> ("In general, the use and deployment of new schemes in the Internet
> infrastructure may be costly; ...", etc.)

Removed CREF2 and closed ticket.

> 
> ...
> 
> Section 4
> 
> re: [[CREF4: Open issue: previously this also RECOMMENDED following the
>     same guidelines as for permanent registration.  However, this higher
>     bar disincented people to register schemes at all, and hence
>     interfered with the goals of the registry.  Hence tentatively
>     removed, but need to confirm consensus on this.  --DT]]
> 
> I've not seen any cases where this has been a problem, but maybe that's
> because I mainly see a self-selecting population ;)  (I.e. those who have actually
> submitted a registration request.)

This was discussed at IETF 89 and there was rough consensus in the room for
lowering the bar for Provisional.

> Some time ago, we started creating a FAQ/guidance page at IANA for a similar
> registry (message header fields), with the goal of demystifying the process and
> encouraging early registration.  Unfortunately, that effort fizzled (though I think
> an initial draft is still around on an IETF/IANA wiki page.)
> 
> Maybe this kind of approach would be an alternative?  I.e. create a FAQ, and
> direct readers to that page for provisional registration.  The FAQ-as-guidance
> can then be updated more easily than the BCP document (within its defined
> constraints).

I have no objections if people want a wiki page too.  But since I can tell you
most people defining (non-IETF) schemes don't read RFC 4395 or register
their schemes, so they might not find or read a wiki page either.

In some sense Wikipedia's page IS that wiki page already.

> 
> ...
> 
> Section 7.1
> 
> [[CREF8: Open Issue: Should Provisional status just use First Come
>     First Serve?  Someone suggested FCFS with Expert Review afterwards,
>     but the benefit and efficacy of a subsequent Expert Review seems
>     dubious to me and might only serve to deter registrations in the
>     first place, which is the problem we're trying to solve.  --DT]]
> 
> Given the limited nature of URI scheme name space, I think that IESG/IANA
> should always have final say about name allocation.  Given that we try to keep
> the bar low, I feel formal FCFS makes it too easy to use provisional registration
> as a land grab - writing that into the spec would make it harder for an expert
> reviewer to push for alternatives where appropriate.  (I think there is one
> occasion in the past few years where the choice of name has been cause for
> push-back, so it's not a great problem.)
> 
> As reviewer, I have tried to treat the role as providing guidance rather than as
> gatekeeper (I don't think I've ever recommended rejection of a provisional
> registration request, though I do often make comments), so I'm a little troubled
> by the perception that expert review is a deterrent.  Can we do something in
> the spec language to make this less of a concern?
> 
> E.g. "The purpose of expert review applied to provisional registration is not
> intended to impose onerous requirements on the proposals offered, but as a
> light-touch process to promote effective cooperative use of URI scheme name
> space."

I responded to this already, but will now note that this was discussed at IETF 89
and there was rough consensus in the room for FCFS with a Notes column, but
also to ask for input from the W3C on this change.

> 
> ...
> 
> Section 7.1:
> 
> [[CREF9: TODO: We don't want this.  --??]]
> 
> I'm not sure what it is you don't want.

I responded to this earlier too (by saying the "??" isn't me, so I don't know :)

> I think it is useful that the IESG can be final arbiter, as it provides some room
> for making decisions that are not in strict accordance with the process
> requirements, without kicking the door open to making arbitrary and capricious
> decisions.  There have been a few cases (I forget details) where the specific
> drafting of the process has seemed to be at odds with a common sense "do the
> right thing" approach - having a way to accommodate these within a clearlhy
> documented framework seems useful to me.

I wonder if the issue is that the sentence it's attached to (below) implies the
IESG is informed after the fact rather than having to approve a procedure variance:

   If parties achieve
   consensus on a registration proposal that does not fully conform to
   the strict wording of this procedure, this should be drawn to the
   attention of a relevant member of the IESG.

But having to approve it makes the process less lightweight and non-contentious.
I'm happy to remove the cref unless a co-author objects and explains the issue :)

> 
> ...
> 
> Section 7.2:
> 
> [[CREF10: Open Issue: I think the last
>         phrase above about RFC 3978 is problematic, as it just serves to
>         discourage registration.  For example, third-party registrations
>         may have no way to grant such rights or make such assertions.
>         Similarly, a standard published by another SDO may have policy/
>         process issues having a request treated as an IETF contribution.
>         Recommend deleting this sentence.  --DT]]
> 
> I'd suggest that at least the registration template submitted to IANA be treated
> as "IETF contribution", even if the rest of the document cannot, since IANA may
> need to republish that much.  The registration template itself can be short and
> consist mainly of pointers to other documents, so I don't think that should be a
> great disincentive.

This is linked to the issue of whether some fields can be moved into the
defining document (which might not be treated as an IETF contribution)
out of the registration template (which is treated as an IETF contribution).

At IETF 89, it was agreed by those in the room that it was okay in principle
to move fields with technical information (other than the scheme name)
into the defining document.  So I think that results in resolving this open issue
as you suggest.

> 
> ...
> 
> Section 7.2:
> 
>    [[CREF11: Open Issue: Say
>     more about guidance to the Designated Expert.  Under what
>     circumstance should this happen?  --DT]]
> 
> I'm not sure what guidance you have in mind here.  Generally, I'd expect
> upgrades from provisional to permanent to meet the same requirements as
> permanent registrations (with provision for IESG last-say as noted above).
> 
> That's pretty much covered in section 7.3.

I responded in other email already with an explanation of the question.
(The email you responded to with "TL;DR" :)

> 
> ...
> 
> [[CREF12: Open Issue: Some of the fields above may serve to deter
>     registration.  Should some of them NOT be required for Provisional
>     registrations (including third-party ones)?  For example, the
>     requirement to have clear security considerations is not appropriate
>     for third-party registrations.  Typically one is forced to fill in
>     something like "Unknown, use with care."  These seem to me to be more
>     appropriate inside the specification (if any) in the references,
>     rather than being required in the request template.  Thus, as new
>     specifications update the uses (e.g., allow use with another HTTP
>     method), the IANA registry itself shouldn't be required to be
>     updated.  --DT]]
> 
> Fair points.  Part of the problem here, I think, is that the template serves two
> purposes: (a) registering a scheme that is fully described elsewhere, in which
> case its mainly a pointer to that specification, and (b) describing a scheme in
> use that is not described in another document (which could really apply only for
> provisional or historic schemes).

I think the goal now is (a) and specifically not (b).  To accomplish (b), you 
can create some other document or wiki page (which need not necessarily
be an "IETF contribution") and point to it.

> 
> I think the headings (especially security considerations) are useful as
> reminders of things to think about and maybe provide additional information.
> 
> Maybe the template could be restructured as key information (Name, status,
> context of use, contact, change controller, and references); then have
> "Additional information" with sub-headings to be filled in as required, and all
> optional for provisional registrations?
> 
> ...
> 
> Thanks,
> 
> #g

Thanks for the careful review,
-Dave

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 30 Mar 2014 18:21:57 +1100

Responses inline.

> require the existence of a protocol.

WFM. That last point might be worth making explicit -- e.g.,

"Discourage use of the same scheme name for different mechanisms (often, but not always, protocols)."

> Otherwise, if I think it's unambiguous already, I'll leave it to see if anyone

OK. /me waits for Julian...

> So if you avoid dot-segments, you don't need to tell what delimits them from other stuff.

Right. I just find it odd that we SHOULD-prohibit the string ".." in a URI scheme where it can't be mistaken for a relative reference (because there are no "/"). 

I.e., avoiding one of them, not both, is sufficient to prevent being mistaken for a relative reference, so why are we overly restrictive here?

> MUST so this isn't the only such occurrence.

OK.

>   within valid character sequences in a URI.

WFM.

>   POST, PUT, and a number of other methods available through the

Thanks.

>   invoked (or "dereferenced") by an application.

See:
  <http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-4.2.1>

> Yep.  This was in RFC 4395 but will change for consistency.

Thanks.

> you can be tracked down and interrogated :)

I understand. Still against it; we should give the people who want to use schemes badly a better mechanism, not accommodate the misuse.

> The rough consensus in the room was not to allow this, hence removed cref2

Understood.

> that you can't track down to someone, which is IMO a worse state.

Do we have any evidence that people are using domain-based URI schemes?

> "that is not limited to" in the hopes that's clearer.

OK.

> If so, can you give an example of what you'd like to see?

"""

   3.  If the registration request is for a Permanent registration:

       1. Review the requirements for Permanent Scheme Definitions in Section 3.

        2. ...
"""

Actually, Section 3 should probably be entitled "Requirements for ..." not "Guidelines for..." since its second. sentence says they're REQUIRED.

A corresponding step for non-Permanent registrations would also be good.

> for changing Provisional to FCFS.

OK.

Thanks,

--
Mark Nottingham   http://www.mnot.net/

---

From: Graham Klyne <[email-masked]>
Date: Mon, 31 Mar 2014 13:27:56 +0100

> I.e., avoiding one of them, not both, is sufficient to prevent being mistaken for a relative reference, so why are we overly restrictive here?

Er, thinking about:

     http://example.org/.

and maybe:

     foo://example.org/.

Is just "." a relative reference or a full path?

I think the question is moot unless one has a base URI like

     foo//example.org/bar/

where there's a '/' in the base URI path.  So maybe avoiding the '/' is enough?

Just checking.

#g
--

---

From: Dave Thaler <[email-masked]>
Date: Mon, 31 Mar 2014 20:36:39 +0000

Mark Nottingham wrote:
[...]
> but not always, protocols)."

Done.

> >> * 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?
> >
> Right. I just find it odd that we SHOULD-prohibit the string ".." in a URI scheme
> where it can't be mistaken for a relative reference (because there are no "/").
> 
> I.e., avoiding one of them, not both, is sufficient to prevent being mistaken for a
> relative reference, so why are we overly restrictive here?

Added this as an open issue (added cref into doc, and filed ticket #26).
 
> >> 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

I read that but am still having a hard time coming up with any generic text,
since URIs may not apply to an "origin server" as in that reference.

As noted in the problem statement document, one of the most common default
operations is essentially "launch the app associated with the scheme name, 
and let it use the rest of the URI as arguments to do something".

> >> * CREF3 - As per above, I think that allowing domain-based URI
> >> schemes is a Bad Idea. What's the use case?
> >
> > I don't want to disallow existing things that are already legal unless
> > there's strong consensus to do so, since that won't cause people to
> > use unregistered schemes, removing that guidance would just cause
> > people to use unregistered schemes that you can't track down to someone,
> which is IMO a worse state.
> 

Yes (although the absence of evidence doesn't imply non-use, but evidence of
use may imply it's probably more common than we know).

We have two pieces of immediate evidence:

1) com-eventbrite-attendee is registered by eventbrite.com
2) appurl.org claims to have a "growing list of supporters" with icons on their
site, and they say to use forward (not reversed) domain-name based URI schemes.

> >> * 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 :)
> >

Done.

> Actually, Section 3 should probably be entitled "Requirements for ..." not
> "Guidelines for..." since its second. sentence says they're REQUIRED.

Done.

-Dave

---

From: Ted Hardie <[email-masked]>
Date: Mon, 31 Mar 2014 15:51:33 -0700

Fading memory comment in-line.

> detecting URIs in plaintext might actually work better if it's violated.
So, my memory on this is a bit faded (and I don't have access to the email
stream any more), so I'd be happy to be corrected, but my memory boils down
to this following language in RFC 2718 (see RFC 2718, section 2.1.2).  I
think there was some additional disccusion about  cases where you can't
tell the difference between a hierarchical structure and a flat namespace.
RFC 3986 has the following:

   URIs that identify in relation to the end-user's local context should only be
   used when the context itself is a defining aspect of the resource,
   such as when an on-line help manual refers to a file on the end-
   user's file system (e.g., "file:///etc/hosts").

If someone proposed a scheme where this is the only available context, is
it hierarchical or not?  That is, for a scheme "fleen" where all references
must be to the top of a local hierarchy ( fleen:///example or gtld://aero
),  is the implied hierarchy enough to let you use the // construct, or
should it be fleen:example and gtld:aero?)  Or is it up to the registrant
to decide?

Has anyone tried to wiggle through the SHOULD NOT to use it, or is it just
cleaning up the language here?

Ted

> there's strong
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>