Re: [lemonade] WGLC streaming

[Neil Cook <[e-mail]>]

Alexey,

thanks for the comments, I was getting worried nobody has read it,  
and I knew it needed thorough review.

Responses below:

Neil.

On 27 Mar 2007, at 11:18, Alexey Melnikov wrote:

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

Ok.

> 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}"

ok.

> 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"
>
Ok

> 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.
>
As Dave mentioned, the client may know better. Perhaps I should that  
that the server lists the preferred order, but the client may choose  
to ignore the order if it knows better.

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

ok
>>    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?

Well this is a tricky one. I would actually prefer it if it was,  
because it means I wouldn't have to extend both netann and mscml with  
c-t-e parameters. What is the likelihood of getting IMAP URL modified  
to allow binary fetches?

> 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 '"'?
>

RFC 4240 says not.

>   Content-Type: application/sdp
>   Content-Length: 481
>
> Here an in all other examples: extra empty line needed after the
> Content-Length line?
>

Yes, there should be - that is a formatting bug.

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

Ok, I'll look that up and confirm.

>
>>  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.
>
I tried to leave out non-essential responses in the flow diagrams. If  
anyone has any strong objection that that, please let me know. They  
are really just to show overall flow, not show every protocol exchange.

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

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

Yes, host from RFC 3986 looks good. However, looks like only IPv6  
addresses need to be enclosed in [].

BTW, what is the form for including ABNF definitions from other RFCs?  
Do I just copy the whole set of definitions out, or can I reference  
them in a standard way?

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

Yep.

>
>>   ms-tuple = host ":" port (":" "authuser")
>>
> I think this should be:
>
>   ms-tuple = host ":" port [":" "authuser"]
>
> as the last component is optional.

Yes, that is what I meant.

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

The text is wrong.

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

Yes, I'll move the METADATA annotation stuff into a separate IANA  
Considerations section.

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

Agreed. I will create an Informative References section.

Neil.


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