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

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 Apr 2014 15:13:34 +1100

On 1 Apr 2014, at 7:36 am, Dave Thaler <[email-masked]> wrote:

>>>> * 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.
>> 
>> See:
>>  <http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-4.2.1>
> 
> 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".

I think that can be accommodated by limiting the suggestion to URLs that are for networked information.

E.g.,

"""
When a scheme can be used as a locator for information on a network, its definition is encouraged to define a default operation for use when "dereferencing" URLs that use that scheme, as per [AWWW]. When such a default operation is defined, it SHOULD be safe;  i.e., the client does not request, and does not expect, any state change origin server as a result of dereferencing the URI.
"""

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

---

From: Larry Masinter <[email-masked]>
Date: Mon, 7 Apr 2014 05:21:10 +0000

Mark and Dave changed ""discourage use of the same scheme name for different
purposes" to "Discourage use of the same scheme name for different mechanisms (often,
but not always, protocols)."

But personally, I think the old text is better. The whole sentence is in the context of just explaining why the rules are the way they are, and whether or not two uses are "the same" is a matter of judgment, and the fact that  scheme names aren't exactly protocol names is irrelevant. If you want to note the relation between scheme names and protocols, put it in a separate paragraph.

"...the first part of a URI is not an artistic indicator..." suggested dropping "artistic". But I think dropping "artistic" weakens the intent, which is to discourage use of "://" as a design pattern "URL's should have colon-slash-slash so people will recognize it as a URL".  You could change "artistic" to "stylistic". URLs are both protocol elements and presentational  elements, but the syntax should be functional.

> > This is straight from RFC 4395.   It says they [non-hierarchical schemes] SHOULD avoid both "/" and dot-segments.
> > 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?

> Added this as an open issue (added cref into doc, and filed ticket #26).
 
If the scheme isn't actually hierarchical, but gets set as a "base" (as can happen), then you can get  nonsense out of relative processing in a way that might be confusing.
 
# 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".

This is a good way of saying it. You might also note "Consider defining
a MIME type instead" in such cases.

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

They're guidelines that include requirements as well as other advice.