Subject: [Uri-review] review request for provisional URI scheme "rtmfp"

From: Michael Thornburgh <[email-masked]>
Date: Mon, 4 Aug 2014 18:57:20 +0000

i would like to register URI scheme "rtmfp" in the provisional registry.  in accordance with RFC 4395, i request review of this request.  the registration template is the IANA Considerations section of draft-thornburgh-rtmfp-flash (Section 6.1 of draft-thornburgh-rtmfp-flash-05, which is the current revision).  for convenience, the request template is also reproduced below.
 
thank you.

-michael thornburgh
 author, draft-thornburgh-rtmfp-flash

---
   The syntax and semantics of this URI scheme are described using the
   Augmented Backus-Naur Form (ABNF) rules from RFC 3986.
   The term "this memo" means draft-thornburgh-rtmfp-flash.

   URI scheme name:  rtmfp

   Status:  provisional

   URI scheme syntax:

      rtmfp-uri-scheme = "rtmfp:"
                       / "rtmfp://" host [ ":" port ] path-abempty

   URI scheme semantics:  The first form is used in the APIs of some
      applications to indicate instantiation of an RTMFP client
      according to this memo, but without connecting to a server.  Such
      an instantiation might be used for pure peer-to-peer
      communication.

      The second form provides location information for the server to
      which to connect, and optional additional information to pass to
      the server.  The only operation for this URI form is to connect to
      a server (initial candidate address(es) for which are named by
      host and port) according to Section 5.3.  The UDP port for initial
      candidate addresses, if not specified, is 1935.  If the host is a
      reg-name, the initial candidate address set SHOULD comprise all
      IPv4 and IPv6 addresses to which reg-name resolves.  The semantics
      of path-abempty are specific to the server.  Connections are made
      using RTMFP as specified by this memo.

   Encoding considerations:  The path-abempty portion of the URI is
      encoded in UTF-8.

   Applications/protocols that use this URI scheme name:  The Flash
      runtime (including Flash Player) from Adobe Systems Incorporated,
      communication servers such as Adobe Media Server, and
      interoperable clients and servers provided by other parties, using
      RTMFP according to this memo.

   Interoperability considerations:  This scheme requires use of RTMFP
      as defined by RFC 7016 in the manner described by this memo.

   Security considerations:  See Security Considerations (Section 7) in
      this memo.

   Contact:  Michael Thornburgh, Adobe Systems Incorporated,
      <[email-masked]>.

   Author/Change controller:  Michael Thornburgh, Adobe Systems
      Incorporated, <[email-masked]>.

   References:
      Thornburgh, M., "Adobe's Secure Real-Time Media Flow Protocol",
      RFC 7016, November 2013.

      This memo.

---

From: Graham Klyne <[email-masked]>
Date: Tue, 05 Aug 2014 15:47:41 +0100

Hi Michael,

A possible problem and a nit:

1.  saying "The path-abempty portion of the URI is encoded in UTF-8." sounds 
like a contradiction. URIs use 7-bit ASCII characters.  RFC3986 discusses using 
%-encoding of UTF-8 character sequences for URIs: is that what you mean?  IRIs 
use Unicode code points (I think, but I'm not up to speed on the details, so I 
invite other to correct me here).  Overall, I don't know what this is trying to 
say, so I think it could be stated more clearly, preferably by reference to some 
existing specification.

2. The scheme is described as being used in Flash only.  This seems to me to be 
a rather narrow scope for a URI scheme registration - the value of URIs is that 
they can be used uniformly across a range of different application environments, 
including in the Web at large.  A scheme like this would be way more useful if 
it could be framed more generally than for use by just Flash.

   There is a proposal to update the URI registration scheme, with broad support 
in the IETF apps area working group, that suggests that private-use schemes 
should use scheme names in a namespace based on the owners domain name:

    http://tools.ietf.org/html/draft-appsawg-uri-scheme-reg-00#section-6
    http://tools.ietf.org/html/draft-appsawg-uri-scheme-reg-00#section-3.8

While this is not yet a requirement, if this scheme really is for use by Flash 
alone, then a scheme name of the form:

    com.adobe.rtmfp

might be more appropriate.

#g
--

On 04/08/2014 19:57, Michael Thornburgh wrote:
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: Dave Thaler <[email-masked]>
Date: Wed, 6 Aug 2014 17:21:18 +0000

FYI, current I-D links are
http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-02#section-6
http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-02#section-3.8

The links in the email below are from an older version prior to WG adoption.

-Dave

> -----Original Message-----
> From: Uri-review [mailto:[email-masked]] On Behalf Of
> Graham Klyne
> Sent: Tuesday, August 5, 2014 7:48 AM
> To: Michael Thornburgh; [email-masked]
> Subject: Re: [Uri-review] review request for provisional URI scheme "rtmfp"
> 
> Hi Michael,
> 
> 1.  saying "The path-abempty portion of the URI is encoded in UTF-8."
> sounds like a contradiction. URIs use 7-bit ASCII characters.  RFC3986
> discusses using %-encoding of UTF-8 character sequences for URIs: is that
> what you mean?  IRIs use Unicode code points (I think, but I'm not up to
> speed on the details, so I invite other to correct me here).  Overall, I don't
> know what this is trying to say, so I think it could be stated more clearly,
> preferably by reference to some existing specification.
> 
> 2. The scheme is described as being used in Flash only.  This seems to me to
> be a rather narrow scope for a URI scheme registration - the value of URIs is
> that they can be used uniformly across a range of different application
> environments, including in the Web at large.  A scheme like this would be
> way more useful if it could be framed more generally than for use by just
> Flash.
> 
>    There is a proposal to update the URI registration scheme, with broad
> support in the IETF apps area working group, that suggests that private-use
> schemes should use scheme names in a namespace based on the owners
> domain name:
> 
> > i would like to register URI scheme "rtmfp" in the provisional registry.  in
> accordance with RFC 4395, i request review of this request.  the registration
> template is the IANA Considerations section of draft-thornburgh-rtmfp-flash
> (Section 6.1 of draft-thornburgh-rtmfp-flash-05, which is the current
> revision).  for convenience, the request template is also reproduced below.
> >
> > thank you.
> >
> > -michael thornburgh

---

From: Michael Thornburgh <[email-masked]>
Date: Wed, 6 Aug 2014 18:21:53 +0000

hi Graham, Dave.  thanks for your responses.  my replies are inline.

> From: Dave Thaler [mailto:[email-masked]]
> Sent: Wednesday, August 06, 2014 10:21 AM
> To: Graham Klyne; Michael Thornburgh; [email-masked]
> Subject: RE: [Uri-review] review request for provisional URI scheme "rtmfp"
> 

thank you.  these links are helpful.

> > preferably by reference to some existing specification.

you're right. i will change the "Encoding considerations" part of the template in draft-thornburgh-rtmfp-flash to "None" as the default rules are the correct rules.

> > might be more appropriate.

the scheme is described as being used by Flash Player, other Adobe products, and "interoperable clients and servers provided by other parties".  non-Adobe implementations currently exist.  hopefully more will exist with the publication of the material in draft-thornburgh-rtmfp-flash as an Informational RFC.

this URI scheme has been in use and widely deployed in the open Internet since 2008. its use is not limited to a private environment within a single organization.  as such, i believe this use meets the guidelines for a provisional URI scheme registration according to Section 4 of draft-ietf-appsawg-uri-scheme-reg-02.

-michael thornburgh

---

From: Michael Thornburgh <[email-masked]>
Date: Wed, 6 Aug 2014 19:00:27 +0000

> you're right. i will change the "Encoding considerations" part of the template in draft-thornburgh-
> rtmfp-flash to "None" as the default rules are the correct rules.

while "None" might have been sufficient, that's not quite right either. the next revision of draft-thornburgh-rtmfp-flash will have this replacement text for the "Encoding considerations" of the URI registration template in the IANA Considerations section:

	<t hangText="Encoding considerations:">The path-abempty component
		represents textual data consisting of characters from the
		Universal Character Set. This component SHOULD be encoded
		according to Section 2.5 of RFC 3986.</t>

-michael thornburgh

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 06 Aug 2014 16:25:03 +0900

Hello Michael,

>        according to this memo, but without connecting to a server.  Such

"according to this memo" is ambiguous. If you mean RFC 7016, then say 
so. Similarly below.

[This is the result of taking a piece of text out of its context, or of 
not planning for that in advance.]

>     Encoding considerations:  The path-abempty portion of the URI is

It's great (or hopefully I should say these days, just obvious) that you 
specify UTF-8 here, but I guess you should also say that the UTF-8 is 
then encoded with percent-encoding. Otherwise, strictly speaking, you 
may have an IRI and not an URI.

Regards,   Martin.

---

From: Michael Thornburgh <[email-masked]>
Date: Tue, 12 Aug 2014 19:53:44 +0000

hi Martin. thanks for your reply.  my replies are inline, and i've trimmed the inclusion.

> On 2014/08/05 03:57, Michael Thornburgh wrote:
[...]
> >     The term "this memo" means draft-thornburgh-rtmfp-flash.
[...]
> not planning for that in advance.]

the canonical version of this template is in draft-thornburgh-rtmfp-flash.  i copied it to the mailing list here for convenience.  note at the top of the template i stated

in the actual draft, it means the draft it's in.

[...]
> may have an IRI and not an URI.
[...]

i addressed this in the mailing list in response to Graham. please see

  http://www.ietf.org/mail-archive/web/uri-review/current/msg01779.html
  http://www.ietf.org/mail-archive/web/uri-review/current/msg01780.html

i should have a new revision of draft-thornburgh-rtmfp-flash posted early next week with change i indicated.

thanks!

-michael thornburgh