Subject: [lemonade] WGLC streaming

From: Eric Burger <[email-masked]>
Date: Wed, 21 Mar 2007 23:56:33 +0100

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

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Mar 2007 11:18:41 +0100

Eric Burger wrote:

>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:[email-masked]; \
   play=imap://[email-masked]/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.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 27 Mar 2007 16:06:57 +0000

I've skimmed the document, too.

On Tue Mar 27 11:18:41 2007, Alexey Melnikov wrote:
> 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:
> 
Yes, this would be good.

> (i.e. an extra space before "UID" and change "{127}" to "{62}"
Actually, no... It *should* be using BODYSTRUCTURE to find the media 
type - by the time you know that section 1.2 (or 1.2.MIME) exists, 
you already know the media type of the part, and its encoding.

> I would prefer is the order specified by the server is the 
I'm not sure it matters overmuch. It might be that the client can 
identify which server is closest better than the server. It really 
depends upon what we mean by "preferred".

> Would it be better if IMAP URL is extended to allow for binary 
I think that might well be neater, although it depends on which 
extension requires more work.

> 7). Flow diagrams in section 2.9 don't show IMAP responses. This 
I think it'd be clearer if they were there. (Again, this is FETCH 
BODY[MIME], rather than FETCH BODYSTRUCTURE).

> as the last component is optional.
I'm concerned with IPv6 behaviour with this production. I'm also 
thinking that perhaps a URI form would be more suitable, as it allows 
for more expansion capability. Assuming, that is, that these media 
services have URIs to them.

> registration of new SIP, etc. parameters.
The Metadata annotation registration is in 2.3, but yes, it needs to 
be moved.

Further comments - and please note that the majority of the SIP stuff 
goes shooting over my head:

In the Security Considerations section, there seems to be a sudden 
lack of references. In particular, sips, SIP, RFC4240, RFC4722, and 
S/MIME all lack references (although they're in the Normative 
References section).

The IMAP base specification, and URLAUTH, also has recommendations 
concerning encryption layers in conjunction with authorized URLs - 
you may find it better to simply include the security considerations 
in both RFC3501 and URLAUTH by reference. Typically, you'd do this 
with this text replacing the first two paragraphs:

"This document proposes the use of URLAUTH [URLAUTH] "pawn tickets", 
received over IMAP [IMAP], and transmitted over SIP [SIP], possibly 
within the MSCML payload of IVR [RFC4722]. As such, the security 
considerations in all these documents apply to this specification.

In summary, as the authorized URLs may grant access to data, 
implementors of this specification need to consider the following:"

Or something similar, anyway.

Section 4: The Great DRM Can Of Worms:

If I were a lawyer, then aside from the fact I'd never read a 
technical document, I'd be concerned with the phrase "[...] also 
implicitly gives the creator [of the URLAUTH authorized URL] the 
right to pass that reference on to any third party it desires." This 
phrase implies that the document authors believe that transmission of 
media via email grants the recipient rights to redistribution, which 
is probably not the view of most people, DRM-fans or not.

Without delving into the precise legal terminology required, I'd say 
that the use of URLAUTH in this specification is believed to be 
persuant with, and used only for, the execution of those rights to be 
expected when media is sent via traditional internet messaging, and 
causes no duplication of media content which is not essentially 
provided by the action of sending the message; that is, the use of 
the content for downloading and viewing, which *is* implicitly 
granted by the sender of the message, in as much as the sender has 
the right to grant such rights.

I might also state that any DRM required needs to be implemented 
within the media type, and moreover to take into account that the use 
of this specification requires a third party to access the media 
content in order to provide efficient private streaming.

I'm very much against implementing DRM checks in URLAUTH, which would 
require me to maintain a somehow perfect list of media types which 
require DRM checks, and presumably open my employer to DRM related 
lawsuits should I fail to comply.

As a final comment, I believe this specification needs careful review 
by a suitable working group (or groups) within the SIP community - 
could I suggest that the Chairs, or Secretary, arrange this with the 
RAI review team, or RAI ADs?

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Mar 2007 16:23:47 +0100

Dave Cridland wrote:

> type - by the time you know that section 1.2 (or 1.2.MIME) exists, you 
> already know the media type of the part, and its encoding.

I thought about this too. But at least the current example needs to be 
fixed.
[...]

> I'm concerned with IPv6 behaviour with this production.

Good point.

> I'm also thinking that perhaps a URI form would be more suitable, as 
> it allows for more expansion capability. Assuming, that is, that these 
> media services have URIs to them.

That would be fine with me, however this would require some changes to 
how ms-tuples are delimited.
Also this would mean that the username is explicit, which might be a 
good thing anyway

---

From: Neil Cook <[email-masked]>
Date: Thu, 29 Mar 2007 14:55:52 +0100

Alexey,

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

Responses below:

Neil.

> unusual for IMAP and not specified in the conventions. I suggest just

Ok.

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

ok.

> Insert extra space before the "UID"
Ok

> I would prefer is the order specified by the server is the  
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 at least one more occurrence later in the same section)

ok
> Would it be better if IMAP URL is extended to allow for binary content

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?

> A curiosity question: does the content of the play parameter has to be

RFC 4240 says not.

> Here an in all other examples: extra empty line needed after the

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

> draft-ietf-lemonade-rfc2192bis-04.txt recommends using SASL ANONYMOUS.

Ok, I'll look that up and confirm.

> 7). Flow diagrams in section 2.9 don't show IMAP responses. This might
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.

> typo: Note that if one ...
Ok.

> If you don't want that, you need to find more suitable productions in

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?

> quoted strings. I think you want to use the "port" non-terminal  

Yep.

> as the last component is optional.

Yes, that is what I meant.

> So you either need to fix the text in Section 2.3 or the ABNF.

The text is wrong.

> registration of new SIP, etc. parameters.

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

> Also, I would like to suggest that the reference to RFC 2192 be  

Agreed. I will create an Informative References section.

Neil.

---

From: Neil Cook <[email-masked]>
Date: Thu, 29 Mar 2007 15:18:26 +0100

Dave,

> Actually, no... It *should* be using BODYSTRUCTURE to find the  
> media type - by the time you know that section 1.2 (or 1.2.MIME)  
> exists, you already know the media type of the part, and its encoding.

Actually the reason I used BODY there was more for clarity, to show  
the MIME information for that particular bodypart. BODYSTRUCTURE  
shows the media type for all the bodyparts, and so is less clear.

> BODY[MIME], rather than FETCH BODYSTRUCTURE).

I'd be okay with adding the IMAP responses if folks think it would  
make it clearer. Again, the FETCH BODY[MIME] is just to match with  
the previous example. I don't think this document is going to be used  
as a guide to writing IMAP clients, or how to retrieve body structure.

> thinking that perhaps a URI form would be more suitable, as it  
> allows for more expansion capability. Assuming, that is, that these  

Well using the "host" ABNF from RFC 3986 would cover the various  
forms of IPv6 etc.

> The Metadata annotation registration is in 2.3, but yes, it needs  
> to be moved.
>
> Further comments - and please note that the majority of the SIP  
> stuff goes shooting over my head:
>

I have been in somewhat of a quandry about that. Do I reference  
*everytime* I mention another standard? I got the feeling that by the  
end of the doc, if various protocols have been referenced enough,  
they probably don't need any more, but I'd be happy to be corrected  
on that. Obviously any in that section which haven't been referenced  
before should be referenced.

> you may find it better to simply include the security  
> considerations in both RFC3501 and URLAUTH by reference. Typically,  
> you'd do this with this text replacing the first two paragraphs:
>
> "This document proposes the use of URLAUTH [URLAUTH] "pawn  
> tickets", received over IMAP [IMAP], and transmitted over SIP  
> [SIP], possibly within the MSCML payload of IVR [RFC4722]. As such,  
> the security considerations in all these documents apply to this  
> specification.
>
> implementors of this specification need to consider the following:

That's a good idea. I'll try and wordsmith something similar to that.

> right to pass that reference on to any third party it desires."  
> This phrase implies that the document authors believe that  
> transmission of media via email grants the recipient rights to  
> redistribution, which is probably not the view of most people, DRM- 
> fans or not.
>
> Without delving into the precise legal terminology required, I'd  
> say that the use of URLAUTH in this specification is believed to be  
> persuant with, and used only for, the execution of those rights to  
> be expected when media is sent via traditional internet messaging,  
> and causes no duplication of media content which is not essentially  
> within the media type, and moreover to take into account that the  
> use of this specification requires a third party to access the  
> media content in order to provide efficient private streaming.
>
> I'm very much against implementing DRM checks in URLAUTH, which  
> would require me to maintain a somehow perfect list of media types  
> which require DRM checks, and presumably open my employer to DRM  
> related lawsuits should I fail to comply.

I took the DRM text mostly from Eric (buck passing ahoy :). I agree  
with your sentiments, in that we shouldn't be implying anything about  
the intent of DRM (or lack of it), only explaining what are the  
implications for DRM of this mechanism.

> As a final comment, I believe this specification needs careful  
> review by a suitable working group (or groups) within the SIP  
> community - could I suggest that the Chairs, or Secretary, arrange  
> this with the RAI review team, or RAI ADs?

Completely agree that someone from the SIP community needs to review.  
Ideally the folks who reviewed MSCML and NetAnn.

Neil.

---

From: Philip Guenther <[email-masked]>
Date: Thu, 29 Mar 2007 15:10:17 -0600

On Tue, 27 Mar 2007, Alexey Melnikov wrote:
...
>  S:  UID 24356 FLAGS (\Seen))

Actually, I think it should read:

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

That is, no trailing semicolon on the content-type (please don't propagate 
that syntax error) and a blank line at the end of the MIME header.

(While RFCs 3501 and 2045 don't specifically say that the blank line 
between the MIME headers and the body of the part--when present--is 
considered part of the MIME header, that definitely *is* true of the blank 
line for message headers returned by BODY[x.y.HEADER], so it's certainly 
more consistent to include it.)

Philip Guenther