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

From: Dave Thaler <[email-masked]>
Date: Sun, 20 Jul 2014 01:09:32 +0000

FYI, this one is still in my queue and will be handled in the next version, and
the changes noted below will be editorial-only.  So I won't mention anything
in this thread in my slides on Monday, to conserve time for technical 
discussion.

> -----Original Message-----
> From: Larry Masinter [mailto:[email-masked]]
> Sent: Monday, April 7, 2014 1:21 AM
> To: Dave Thaler; Mark Nottingham
> Cc: [email-masked]
> Subject: RE: [apps-discuss] New Version Notification for draft-thaler-appsawg-
> uri-scheme-reg-00.txt
> 
> 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.

Will do that.

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

Will add "stylistic".

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

Will remove the cref and close the ticket with that explanation when the cref
is removed.
 
> # 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.

Will do.

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

The draft currently has "Requirements for..."
Since you agree it's both, I will assume it's ok to leave it unless I hear otherwise.
 
-Dave