[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lemonade] WGLC streaming
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:annc at ms2.example.net; \
play=imap://joe at example.com/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
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade