Subject: [AVT] draft-ietf-avt-rtp-vorbis: configuration-uri

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 12 Jun 2007 14:56:24 -0600

In draft-ietf-avt-rtp-vorbis-05 we find:

       configuration-uri:  the URI of the configuration headers in case
          of out of band transmission.  In the form of
          "protocol://path/to/resource/".

This assumes that URIs have a certain structure and that there is a 
resource with a certain media type available at the URI. While that is 
true of many URI schemes (e.g., http: and rtsp:), it is not true of 
other URI schemes (e.g., mailto: and xmpp:). Unless you have a good 
reason for thinking that a configuration-uri must be of the form you 
specify, I think it would be best to generalize the format so that any 
URI that conforms to RFC 3986 can be used.

As an example, we might define a way to retrieve configuration headers 
via XMPP, for which the URI might be something like this:

xmpp:[email-masked]?config;header=resource

The spec goes on to say:

                                           Depending on the specific
          method, a single configuration packet could be retrived by its
          number, or multiple packets could be aggregated in a single
          stream.  Such aggregates MAY be compressed using either bzip2
          [15] or gzip [13].  A sha1 [9] checksum MAY be provided for
          aggregates.  In this latter case the URI will end with the
          aggregate name, followed by its compressed extension if
          applies, a "!" and the base64 [8] representation of the
          sha1hash of the above mentioned compressed aggregated as in:
          "protocol://path/to/resource/aggregated.bz2!sha1hash".  The
          trailing '/' discriminates which of two methods are in use.  It
          MUST follow the associated delivery method parameter (either
          "in_band" or "out_band").

Do you mean that if the URI ends with a trailing slash, then the method 
in use is "simple configuration packet" but if the URI does not end in a 
trailing slash then the method in use is "multiple packets aggregated in 
a single stream"? Again, this seems limited to a specific URI structure, 
since in the XMPP example above we might do something like the following 
for multiple aggregated packets:

xmpp:[email-masked]?config;header=resource;aggregate=aggregated.bz2;hash=sha1hash

Finally, must the configuration-uri be a URI or may it be an IRI?

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Luca Barbato <[email-masked]>
Date: Wed, 13 Jun 2007 02:42:38 +0200

> URI that conforms to RFC 3986 can be used.

The rationale for picking this restricted form is just simplicity, I can
relax the spec so it is RECOMMENDED to structure the configuration-uri
this way.

> xmpp:[email-masked]?config;header=resource

I see a problem

> a single stream"?

Yes.

> Again, this seems limited to a specific URI structure,

";" has a particular use in sdp, this string cannot be delivered in sdp.

What about mapping the former to

xmpp://[email-masked]/aggregated.bz2!sha1hash

and let the application convert it to the format xmpp expect?

Probably xmpp configuration uri would be used just in conjunction with
Jingle and never with sdp so the issue won't happen.

> Finally, must the configuration-uri be a URI or may it be an IRI?

Again I privileged simplicity over features of limited usage. Given that
the URI should be machine generated and machine parsed the IRI
motivation ceases to exist.

BTW I found an error in the SDP example: the first delivery method is
"inline".

It has been fixed already on the xiph svn.

Thank you for the comment.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

---

From: Colin Perkins <[email-masked]>
Date: Wed, 13 Jun 2007 14:41:29 +0100

On 13 Jun 2007, at 01:42, Luca Barbato wrote:
>> xmpp:[email-masked]? 
>> config;header=resource;aggregate=aggregated.bz2;hash=sha1hash
>

We should probably mandate a standard encoding scheme for all types  
of URI, rather than something specific to XMPP. Does the usual URL  
encoding (with % codes) work?

-- 
Colin Perkins
http://csperkins.org/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 13 Jun 2007 09:15:06 -0500

> relax the spec so it is RECOMMENDED to structure the configuration-uri

That's fine with me.

> xmpp://[email-masked]/aggregated.bz2!sha1hash

xmpp://[email-masked] means "authenticate as [email-masked]". Also
XMP URIs are not "hierarchical" in the way that HTTP URIs are. So
xmpp:[email-masked]/aggregated.bz2!sha1hash doesn't mean what you
think it means -- i.e., it doesn't mean "obtain the resource (file)
'aggregated.bz2' with SHA1 hash 'sha1hash' from the XMPP entity 
identified by [email-masked]". XMPP URIs are structured differently
(though they still conform to RFC 3986).

> and let the application convert it to the format xmpp expect?

That's what XMPP URIs do -- we don't use them natively. But IMHO the
original URI should conform to RFC 4622.

> Jingle and never with sdp so the issue won't happen.

Right.

As long as the text is changed to say that the format you describe is
recommmended, I'm fine (because we would specify the XMPP URI format in
a different spec anyway).

Peter

---

From: Luca Barbato <[email-masked]>
Date: Thu, 21 Jun 2007 09:40:44 +0200

> a different spec anyway).

This is the proposed clarification, I'm tempted to ditch the
delivery_method since:

* every implementation MUST handle in_band delivery.
* inline delivery is defined by "configuration"
* out_band delivery is defined by "configuration-uri"

That would make the fmtp smaller.

-      configuration-uri:  the URI of the configuration headers in case
-         of out of band transmission.  In the form of
-         "protocol://path/to/resource/".  Depending on the specific
+      configuration-uri:  the URI [4] of the configuration headers in
+         case of out of band transmission.  In the form of
+         "protocol://path/to/resource/", depending on the specific
          method, a single configuration packet could be retrived by its
-         number, or multiple packets could be aggregated in a single
-         stream.  Such aggregates MAY be compressed using either bzip2
-         [15] or gzip [13].  A sha1 [9] checksum MAY be provided for
-         aggregates.  In this latter case the URI will end with the
+         Ident number, or multiple packets could be aggregated in a
+         single stream.  Such aggregates MAY be compressed using either
+         bzip2 [16] or gzip [14].  A sha1 [10] checksum MAY be provided
+         for aggregates.  In this latter case the URI will end with the
          aggregate name, followed by its compressed extension if
-         applies, a "!" and the base64 [8] representation of the
+         applies, a "!" and the base64 [9] representation of the
          sha1hash of the above mentioned compressed aggregated as in:
          "protocol://path/to/resource/aggregated.bz2!sha1hash".  The
-         trailing '/' discriminates which of two methods are in use.  It
-         MUST follow the associated delivery method parameter (either
-         "in_band" or "out_band").
+         trailing '/' discriminates which of two methods are in use.
+         The configuration-uri MUST follow the associated delivery
+         method parameter ("out_band").  Non hierarchical protocols and
+         protocols using for special purposes the '!' separator MAY
+         point just to a resource aggregate using their specific syntax.

I hope it addresses the xmpp issue.

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 21 Jun 2007 09:59:14 -0500

On Thu, Jun 21, 2007 at 09:40:44AM +0200, Luca Barbato wrote:
> This is the proposed clarification

<snip/>

That looks fine to me.

/psa