review request for provisional URI scheme "rtmfp"

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

review request for provisional URI scheme "rtmfp"

Michael Thornburgh
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,
      <[hidden email]>.

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

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

      This memo.

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: review request for provisional URI scheme "rtmfp"

Graham Klyne-2
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:

> 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,
>        <[hidden email]>.
>
>     Author/Change controller:  Michael Thornburgh, Adobe Systems
>        Incorporated, <[hidden email]>.
>
>     References:
>        Thornburgh, M., "Adobe's Secure Real-Time Media Flow Protocol",
>        RFC 7016, November 2013.
>
>        This memo.
>
> _______________________________________________
> Uri-review mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/uri-review
>

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: review request for provisional URI scheme "rtmfp"

Martin J. Dürst
In reply to this post by Michael Thornburgh
Hello Michael,

On 2014/08/05 03:57, Michael Thornburgh wrote:

> 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

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

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

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.

>     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,
>        <[hidden email]>.
>
>     Author/Change controller:  Michael Thornburgh, Adobe Systems
>        Incorporated, <[hidden email]>.
>
>     References:
>        Thornburgh, M., "Adobe's Secure Real-Time Media Flow Protocol",
>        RFC 7016, November 2013.
>
>        This memo.
>
> _______________________________________________
> Uri-review mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/uri-review
>

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: review request for provisional URI scheme "rtmfp"

Dave Thaler-2
In reply to this post by Graham Klyne-2
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:[hidden email]] On Behalf Of
> Graham Klyne
> Sent: Tuesday, August 5, 2014 7:48 AM
> To: Michael Thornburgh; [hidden email]
> Subject: Re: [Uri-review] review request for provisional URI scheme "rtmfp"
>
> 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:
> > 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,
> >        <[hidden email]>.
> >
> >     Author/Change controller:  Michael Thornburgh, Adobe Systems
> >        Incorporated, <[hidden email]>.
> >
> >     References:
> >        Thornburgh, M., "Adobe's Secure Real-Time Media Flow Protocol",
> >        RFC 7016, November 2013.
> >
> >        This memo.
> >
> > _______________________________________________
> > Uri-review mailing list
> > [hidden email]
> > https://www.ietf.org/mailman/listinfo/uri-review
> >
>
> _______________________________________________
> Uri-review mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/uri-review

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: review request for provisional URI scheme "rtmfp"

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

> -----Original Message-----
> From: Dave Thaler [mailto:[hidden email]]
> Sent: Wednesday, August 06, 2014 10:21 AM
> To: Graham Klyne; Michael Thornburgh; [hidden email]
> Subject: RE: [Uri-review] review request for provisional URI scheme "rtmfp"
>
> 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.

thank you.  these links are helpful.

> -Dave
>
> > -----Original Message-----
> > From: Uri-review [mailto:[hidden email]] On Behalf Of
> > Graham Klyne
> > Sent: Tuesday, August 5, 2014 7:48 AM
> > To: Michael Thornburgh; [hidden email]
> > Subject: Re: [Uri-review] review request for provisional URI scheme "rtmfp"
> >
> > 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.

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.

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

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


> >
> > #g
> > --
> >
> >
> > On 04/08/2014 19:57, Michael Thornburgh wrote:
> > > 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,
> > >        <[hidden email]>.
> > >
> > >     Author/Change controller:  Michael Thornburgh, Adobe Systems
> > >        Incorporated, <[hidden email]>.
> > >
> > >     References:
> > >        Thornburgh, M., "Adobe's Secure Real-Time Media Flow Protocol",
> > >        RFC 7016, November 2013.
> > >
> > >        This memo.

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: review request for provisional URI scheme "rtmfp"

Michael Thornburgh
In reply to this post by Dave Thaler-2
> > > 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.
>
> 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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: review request for provisional URI scheme "rtmfp"

Michael Thornburgh
In reply to this post by Martin J. Dürst
hi Martin. thanks for your reply.  my replies are inline, and i've trimmed the inclusion.

> Hello Michael,
>
> On 2014/08/05 03:57, Michael Thornburgh wrote:
[...]
> > ---
> >     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.
[...]
>
> "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.]

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

  The term "this memo" means draft-thornburgh-rtmfp-flash.

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

[...]
> >     Encoding considerations:  The path-abempty portion of the URI is
> >        encoded in UTF-8.
>
> 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.
[...]

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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review