Re: [lemonade] WGLC streaming

[Alexey Melnikov <[e-mail]>]

Eric Burger wrote:

>This is the announcement for the Work Group Last Call on the Streaming Media
>draft:
>http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streaming-01.txt
>
>Work group last call ends April 8.

The document is in a pretty good shape. However examples contain several 
minor bugs and there are also some issues with IANA registrations as 
well as with Normative References. My detailed comments are below:

1). Almost all IMAP examples use trailing '\' to specify line
continuations (and the examples don't use them consistently). This is
unusual for IMAP and not specified in the conventions. I suggest just
removing them.

2). In Section 2.2:

The first example:

>   C: a122 UID FETCH 24356 BODY[1.2.MIME]
>   S: * 26 FETCH (BODY[1.2.MIME] {127}
>   S: Content-Transfer-Encoding: base64
>   S: Content-Type: video/mpeg;
>   S: UID 24356 FLAGS (\Seen))

Should be:

   C: a122 UID FETCH 24356 BODY[1.2.MIME]
   S: * 26 FETCH (BODY[1.2.MIME] {62}
   S: Content-Transfer-Encoding: base64
   S: Content-Type: video/mpeg;
   S:  UID 24356 FLAGS (\Seen))

(i.e. an extra space before "UID" and change "{127}" to "{62}"

The second example:

>   C: a122 UID FETCH 24359 BODY[1.2.MIME]

typo: BODY[1.3.MIME]

>   S: * 26 FETCH (BODY[1.3.MIME] {127}

{62}

>   S: Content-Transfer-Encoding: base64
>   S: Content-Type: audio/G729;
>   S: UID 24359 FLAGS (\Seen))

Insert extra space before the "UID"

3). In section 2.3

>    Clients SHOULD parse the value of mediaServers, (using either the
>    value.priv or value.shared: whichever is available and/or
>    appropriate), and contact a media server using one of the supplied
>    values.  No particular preference order is implied by the ordering,

I would prefer is the order specified by the server is the preferred order.

>    and it is left to the client implementor to decide the algorithm to
>    use when selecting the media server(s) to contact, and the selection
>    of alternates under failure conditions.

4). In section 2.5:

>   Similarly, the message may well be encoded with a content transfer
>   encoding such as base 64.

typo: base-64

(and at least one more occurrence later in the same section)

>    Similarly, the message may well be encoded with a content transfer
>    encoding such as base 64.  However, RFC 4240 does not include a
>    method for communicating content transfer encoding to the media
>    server as part of the announcement service, nor does the URLFETCH
>    command include a mechanism for retrieving message parts without
>    encoding (c.f. the BINARY [17] extension to IMAP).

Would it be better if IMAP URL is extended to allow for binary content
fetching?

5). In section 2.6

C: INVITE sip:[e-mail]; \
   play=imap://[e-mail]/INBOX/;uid=24356/;section=1.2;\
   expire=2006-12-19T16:39:\57-08:00;urlauth=anonymous:\
   internal:238234982398239898a9898998798b987s87920; \
   content-type=video/mpeg; \
   content-transfer-encoding=base64 SIP/2.0

A curiosity question: does the content of the play parameter has to be
surrounded by '"'?

   Content-Type: application/sdp
   Content-Length: 481

Here an in all other examples: extra empty line needed after the
Content-Length line?

6). In Section 2.8:

>   If the media server is not configured as an authorized user of the
>   IMAP server, it MUST authenticate to the IMAP server using the LOGIN
>   command, with the username of "anonymous".
>
I believe this advice is out of date.
draft-ietf-lemonade-rfc2192bis-04.txt recommends using SASL ANONYMOUS.

>  However, in this case, if
>
>   the URL supplied in the 'play' parameter of the SIP INVITE specifies
>   an authorization of 'authuser', then the media server SHOULD NOT
>   attempt to contact the IMAP server, but SHOULD instead immediately
>   return a response code of 404 to the client with a reason phrase of
>   'Not authorized to access resource' reason.
>
7). Flow diagrams in section 2.9 don't show IMAP responses. This might
be Ok.

8). In section 3:

>   This document proposes the use of URLAUTH "pawn tickets" to grant
>   access to message parts.  The goal is for the media server to stream
>   these parts.  INote that f one uses an anonymous pawn ticket, that
>
typo: Note that if one ...

9). In section 5:

>   media-servers = ms-tuple *(";" ms-tuple)
>
>   host = astring
>  
>
If you mean the RFC 3501 "astring" here, then I don't think this is what
you actually want, as it allows for IMAP literals and quoted strings.
I suggest you use "host" non-terminal from RFC 3986. But if you follow
this suggestion, be aware that "host" requires that IP addresses be
enclosed in '[]'.
If you don't want that, you need to find more suitable productions in
RFC 3986.

>   port = nstring
>  
>
This is not what you want either, as this allows for "NIL", literal and
quoted strings. I think you want to use the "port" non-terminal from RFC
3986.

>   ms-tuple = host ":" port (":" "authuser")
>
I think this should be:

   ms-tuple = host ":" port [":" "authuser"]

as the last component is optional.

Also note that section 2.3 says:

   For example, the client could
   discover a tuple of a media server address and an IMAP username,
   which allowed the client to generate a URL which was secure in that
   it could *only* be accessed by a specific (presumably trusted) media
   server.

which seems to suggest that the optional part is a username.
So you either need to fix the text in Section 2.3 or the ABNF.

10). There is no "IANA Considerations" section. One should be added and
contain text about a METADATA annotation registration, as well as the
registration of new SIP, etc. parameters.

11). In section 7:

I believe the following 2 references are Informative, so they should be
moved to a new section:

>   [13]  Newman, C., "Message Submission BURL Extension", RFC 4468,
>         May 2006.
>  
>
[...]

>   [17]  Nereberg, L., "IMAP4 Binary Content Extension", RFC 3516,
>         Apr 2003.
>
Also, I would like to suggest that the reference to RFC 2192 be updated
to point to 2192bis.




_______________________________________________
lemonade mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade