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

From: Dave Thaler <[email-masked]>
Date: Thu, 10 Oct 2013 14:51:32 +0000

This is relevant to appsawg.  Comments welcome.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 10, 2013 7:47 AM
To: Dave Thaler
Subject: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt

A new version of I-D, draft-thaler-uri-scheme-reg-ps-00.txt
has been successfully submitted by Dave Thaler and posted to the IETF repository.

Filename:	 draft-thaler-uri-scheme-reg-ps
Revision:	 00
Title:		 Guidelines and Registration Procedures for New URI Schemes: Problem Statement
Creation date:	 2013-10-10
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-thaler-uri-scheme-reg-ps-00.txt
Status:          http://datatracker.ietf.org/doc/draft-thaler-uri-scheme-reg-ps
Htmlized:        http://tools.ietf.org/html/draft-thaler-uri-scheme-reg-ps-00

Abstract:
   This document describes some problems with the existing guidelines
   and procedures, as documented in RFC 4395, for new URI schemes.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 10 Oct 2013 17:04:18 +0200

>Htmlized:        http://tools.ietf.org/html/draft-thaler-uri-scheme-reg-ps-00

In section 2.1 you write "What if all new applications being submitted
to an app store started sending requests for Provisional URI schemes?"

That would seem to be a spam or denial of service attack scenario, not
people just following best practises, it would seem. Why would we need,
or what good would it do, to have more than a couple of hundred schemes?
At some point schemes are not sufficiently distinct to warrant multiple
top level names. Rather than changing registration guidelines it might
be better to tell people to deploy better delegation mechanisms. An OS
that can dispatch based on the scheme name, but not on anything else in
addresses, is clearly broken, for instance.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Dave Thaler <[email-masked]>
Date: Thu, 10 Oct 2013 15:15:08 +0000

> From: Bjoern Hoehrmann [mailto:[email-masked]]
> Sent: Thursday, October 10, 2013 8:04 AM
> To: Dave Thaler
> Cc: [email-masked]
> Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler-uri-
> scheme-reg-ps-00.txt
> 
> * Dave Thaler wrote:
> In section 2.1 you write "What if all new applications being submitted to an
> app store started sending requests for Provisional URI schemes?"
> 
> people just following best practises, it would seem. Why would we need, or
> what good would it do, to have more than a couple of hundred schemes?

As noted elsewhere in the doc, it's unlikely since there's little/no incentive
to register anyway.

> At some point schemes are not sufficiently distinct to warrant multiple top
> level names.

The quoted guidance about private name spaces is the obvious counter
argument to that (it has wording issues but the intent is valid).

> Rather than changing registration guidelines it might be better
> to tell people to deploy better delegation mechanisms. An OS that can
> dispatch based on the scheme name, but not on anything else in addresses,
> is clearly broken, for instance.

I'd say that ship has already sailed.  If you want to suggest a solution, by all means
write a draft.  This document is just the problem statement.

-Dave

> --
> Björn Höhrmann · mailto:[email-masked] ·
> http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
> http://www.bjoernsworld.de

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 10 Oct 2013 17:47:04 +0200

>write a draft.  This document is just the problem statement.

Let me put it differently. I do not understand how the question quoted
above is useful in understanding the problem the document is stating.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Dave Thaler <[email-masked]>
Date: Thu, 10 Oct 2013 16:16:41 +0000

> Sent: Thursday, October 10, 2013 8:47 AM
> To: Dave Thaler
> >> In section 2.1 you write "What if all new applications being
> >> submitted to an app store started sending requests for Provisional URI
> schemes?"
> 
> >As noted elsewhere in the doc, it's unlikely since there's little/no
> >incentive to register anyway.
> 
> >I'd say that ship has already sailed.  If you want to suggest a
> >solution, by all means write a draft.  This document is just the problem
> statement.
> 

Ok, let me try to answer that.  RFC 4395 defines a set of goals which are
quoted in section 1.  The current mechanism does not meet those goals.
To really meet the stated goals would require the majority of schemes to
be registered.  The current process cannot scale to do so, given current
practice.  Hence we either need to change the process or change the goals
or both.

Does that help?

-Dave

---

From: Tony Hansen <[email-masked]>
Date: Thu, 10 Oct 2013 12:39:07 -0400

> practice.  Hence we either need to change the process or change the goals

Dave, please take a look at draft-ietf-iri-4395bis-irireg. This was an
effort to update 4395 for many of the issues you raise as well as
updating 4395 for IRIs. Work on it paused when the IRI WG imploded.

If you ignore the changes oriented around IRIs, does what is documented
there solve the problems that you bring up? (I admit I have not taken
your document and done a side-by-side check.)

The editors of that draft have discussed resurrecting work on that draft
without the IRI working group, but haven't received the kick in the
pants needed to do so.

    Tony Hansen

---

From: t.petch <[email-masked]>
Date: Fri, 11 Oct 2013 09:48:59 +0100

Dave

What do you mean by
"such that when the URI is accessed"?

Is this the user clicking on an anchor, an API call, both, neither...?
I am used to using URI to access resources, I am not clear what you mean
to access a URI.  I sort of get the feeling that the context of this is
smartphones, of whose technology I am ignorant.

Tom Petch

----- Original Message -----
From: "Dave Thaler" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, October 10, 2013 3:51 PM
Subject: [apps-discuss] FW: New Version Notification for
draft-thaler-uri-scheme-reg-ps-00.txt

> URL:
http://www.ietf.org/internet-drafts/draft-thaler-uri-scheme-reg-ps-00.tx
t
> Status:
http://datatracker.ietf.org/doc/draft-thaler-uri-scheme-reg-ps
> Htmlized:
http://tools.ietf.org/html/draft-thaler-uri-scheme-reg-ps-00
> Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.
>
> The IETF Secretariat
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Dave Thaler <[email-masked]>
Date: Fri, 11 Oct 2013 17:49:59 +0000

Yes, I know, I've reviewed that document many times.   I considered referencing it in my draft
but ended up deleting references to it because it didn't really change the problem statement.
I could add the reference back in in a -01 if it would help.

So in short: no the latest version does not address the issues or I would have just been arguing
for publishing it as is.  However, that is the doc that I would expect the solution to the problems
to be done in, but as I'm not currently a co-author (about the time IRI WG was closed, I did
volunteer to help edit the document as I do think it's important) and because I want to focus
discussion on the problem without presuming a particular solution, I wrote a separate draft
for now that I would expect to go away once we decide on an appropriate direction.

-Dave

From: Tony Hansen [mailto:[email-masked]]
Sent: Thursday, October 10, 2013 9:39 AM
To: Dave Thaler
Cc: [email-masked]
Subject: Re: [apps-discuss] FW: New Version Notification for draft-thaler-uri-scheme-reg-ps-00.txt

or both.

Dave, please take a look at draft-ietf-iri-4395bis-irireg. This was an effort to update 4395 for many of the issues you raise as well as updating 4395 for IRIs. Work on it paused when the IRI WG imploded.

If you ignore the changes oriented around IRIs, does what is documented there solve the problems that you bring up? (I admit I have not taken your document and done a side-by-side check.)

The editors of that draft have discussed resurrecting work on that draft without the IRI working group, but haven't received the kick in the pants needed to do so.

    Tony Hansen

---

From: Dave Thaler <[email-masked]>
Date: Fri, 11 Oct 2013 18:01:05 +0000

Tom Petch writes:
> I am used to using URI to access resources, I am not clear what you mean to
> access a URI.

Both.   I could clarify this in an update to the document, but from a browser it means
clicking on a link.  From another app it generally means an API call.  For example on Windows,
LaunchUriAsync (http://msdn.microsoft.com/en-us/library/windows/apps/Hh701480.aspx)
Is one such API.

> I sort of get the feeling that the context of this is smartphones,
> of whose technology I am ignorant.

Not specific to smartphones.  It happens on many platforms including PCs,
Mac OSX, smartphones, etc.

-Dave

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 16 Oct 2013 10:29:41 +0900

Hello Dave,

> I could add the reference back in in a -01 if it would help.

It would help indeed, in the sense that it would show that you had a 
look at it (which I  guessed, but others may not have known) and also to 
say, in your draft, how it relates to what's in 
draft-ietf-iri-4395bis-irireg.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 16 Oct 2013 10:44:54 +0900

Hello Tony, others,

> updating 4395 for IRIs. Work on it paused when the IRI WG imploded.

It should be pointed out that the IRI WG imploded not because of *I*RI 
issues (i.e. not because of internationalization issues) but because of 
strong differences between browser implementers (or those who claimed to 
represent them on the few occasions they showed up in the WG) and others 
more e.g. with an IETF apps background.

The main differences were:
- Whether to concentrate on how things ought to behave, with occasional 
detours into aberrations of implementations, or how some actual 
implementations behaved, warts and all
- Spec style: IETF style (ABNFs plus additional constraints) vs. 
pseudo-code style
- Whether to create a spec for protocol elements or a spec including 
browser APIs
- What to call the things (URIs/IRIs vs. URLs)
- Whether there was a need to distinguish 'resource' and 'representation'
- Whether to have every change go through a WG approval process or 
whether to have a strong editor who would listen to input when appropriate

> If you ignore the changes oriented around IRIs,

IRI issues are most probably orthogonal to the issues pointed out in 
Dave's draft, and in that sense, they can be ignored.

On the other hand, as far as I remember, most if not all of the changes 
oriented around IRIs are independent from the controversies (sketched 
above) that let to the dissolution of the IRI WG.

> does what is documented

Yes, please resurrect the work on this draft!

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 16 Oct 2013 13:07:37 +0900

> - Whether to create a spec for protocol elements or a spec including

one more:
- Whether to use 'instant' publishing (each change to the spec, however 
minor, results in a new publication) or 'occasional' publishing (such as 
usual with Internet Drafts and RFCs).

---

From: Graham Klyne <[email-masked]>
Date: Wed, 16 Oct 2013 08:51:50 +0100

Hi,

Sorry I'm a bit late to the party here.

(Disclosure: I'm the "expert" reviewer.)

I agree with your premise that the URI scheme registration process doesn't scale 
*if* every application is registered as a separate URI scheme.

I think this suggests a deeper conflict than just the registration process.  Web 
architecture is conceived using a global namespace of URIs, and (for reasons 
covered in RFC4395) adding new schemes in that context can be expensive.

The scenario you raise is one of *local* use of URIs to invoke applications on a 
platform.  It might be argued that this is an abuse of URI schemes, but there is 
clearly some local utility in doing this.  If, in the spirit of "rough consensus 
and running code", we allow such use, how is this to be balanced with the 
concerns of the global web, for which URIs have been defined in the first place?

The web is about content as much, if not more, than about protocols. And URIs 
are part of that content, not just elements in the protocols that drive Web 
interactions.

As reviewer, one question I ask myself when I review a URI scheme registration 
request is "what does this URI identify?".  That's hard to answer coherently 
when it is being used as a protocol trick to fire up an application. 
(Personally, I'd prefer to see application invocation handled more in the style 
of Web Intents (http://www.w3.org/TR/web-intents/) than tying them to URI schemes.)

So my question is: should we promote this proliferation of URI schemes to fire 
up applications?  If so, how are we to reconcile this use with the needs of the 
Web as a global information system?

#g
--

---

From: Larry Masinter <[email-masked]>
Date: Thu, 17 Oct 2013 08:12:52 -0700

I like Dave's draft, and I think it will help set the agenda for reviewing
an updated IRIREG process. I didn't think we were making progress
on irireg precisely because we didn't have an agreed on problem statement.

Of course, what originally led the discussion on irireg was to clarify
the issue of whether a URI scheme was also an IRI scheme, whether
all URIs could be internationalized or did they need processing one
at a time, and whether the scheme definition could be (should be)
in terms of  Unicode code points rather than ASCII characters.

Some other questions that arose during registration process review
included:

Did the scheme define fragment identifiers (no), allowable
"methods" (can you GET, PUT, POST to a URI of various schemes, and
did the scheme definition have to tell you how.

The changes were extensive: 
http://tools.ietf.org/rfcdiff?url1=rfc4395&url2=draft-ietf-iri-4395bis-irireg-04.txt
but worth (I think) re-reviewing.

The issue of dynamic allocation was raised as a discussion of
"registerProtocolHandler" in HTML5. Originally the discussion was
about registering "web+" prefix but I think the main issue is: if web sites 
can cause browsers and OSes to recognize new URI schemes dynamically,
why bother with registering at all, ever?

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06774.html
and I raised this http://www.ietf.org/proceedings/85/slides/slides-85-appsawg-8

some other links:

http://tools.ietf.org/id/draft-castellani-core-advanced-http-mapping-02.txt
http://lists.w3.org/Archives/Public/public-ietf-w3c/2012Sep/0004.html
http://lists.w3.org/Archives/Public/public-html/2012Aug/0115.html
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13904
http://lists.w3.org/Archives/Public/public-ietf-w3c/2012Sep/0035.html