Subject: [lemonade] WGLC streaming - update

From: Eric Burger <[email-masked]>
Date: Thu, 22 Mar 2007 00:54:05 +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 April 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: "Vaudreuil, Greg M \(Greg\)" <[email-masked]>
Date: Tue, 27 Mar 2007 10:42:14 -0500

Resending... The policy filter ate my message.

Greg V.

2nd paragraph of section 1.  SIP does not stream media!  Meda can be
streamed using RTP or RTSP.  SIP invites such.  Wordsmithing needed

text following figure 1.

Bullet 0 should make it clear how the client knows whether there is a
media server and whether the media can be streamed.   Maybe just a
forward pointer to section 2.3x

General comment.  I'm not comfortable with the amount of "go fish" in
the protocol.  The server is not required to support both IVR and NETANN
protocols, so the client is instructed to first try one, and if it
fails, then try the other protocol.  Further, the client given a choice
of separate audio and video media servers (for example) may have to play
go fish across the set.  It would be better to specify at some useful
level (top-level content-type would be sufficient for my needs) the
capabilities of the media server in the IMAP metadata, and to require
the superset IVR service.     Is the idea that media server vendors
don't want to implement IVR to be LEMONADE compliant?  They already have
a bunch of work to support IMAP and the expanded SIP headers (and
corresponding CTE processing). 

Content-transfer-encoding.  I should be more up-to-date on IMAP
binary... I don't have a version in my cache and this is an airplane
message.  But could we not simplify things by requiring the media server
to always use a binary fetch and requring the IMAP server to strip the
CTE to binary?  Saves a SIP extension and teaching media servers about
CTE.  IMAP server already has to do binary for LEMONADE... My memory
suggests we required the ability for the server to unwrap CTE's for
client-server BW savings.

Section 3.  

Why should a client trust a particular media server? "Bad news, your lab
results show you are....."   The client authenticates to the submission
server, so there is some reasonable expectation that the server is
authorized to see message content.  There does not seem to be any
equivalent for the media server.  Maybe there is more trust if you found
the media server identity in METADATA from the IMAP server?  I don't
know if this needs a fix, but it needs a mention in section 3.

Section 4.

This discussion seems to be limited to Forward-Lock DRM.  Crypto-based
DRM may use separate solutions that are between the media server and the
client, where the client provides necessary gunk to unlock the blob
fetched by the media server.  Such solutions don't require any extension
to URLAUTH.

Greg V.

---

From: <[email-masked]>
Date: Wed, 28 Mar 2007 12:50:10 +0300

Hi all,
here are some additional comments to this draft:
1. Title. Would it be OK to remove "Messaging" from the title? One might think MMS here.

2. Conventions: "The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in RFC 2119 [8]."
Interestingly the list of these key words seems to vary from draft to draft (take a look at draft-ietf-lemonade-rfc2192bis-04). Isn't there a consolidated list that could be in every draft?

3. Section 1, paragraph one: "Email clients on resource and/or network constrained devices, such a mobile phones, may have difficulties in retrieving and/or storing large attachments received in a message. For example, on a poor network link, the latency required to download the entire attachment may not be acceptable to the user."
Typo: "such a" -> "such as"
I am not sure how streaming helps network contstrained devices since streaming might be more network-demanding in some cases than a slow fetch. I thought the whole reason of doing streaming was: not to download and store stream-able attachments at all. I've seen streaming on slow networks, and I can tell that I would rather wait longer to retrieve it slowly in the background without streaming. Looking at the phone and waiting for new frames to be drawn is just: bad. Even today, in my office where there is gigabits of bandwidth I still have to wait for some streams for pre-load more than half of the movies (not because there is a network limit, not because there is a client limit, but because there are limitations on the server.) Therefore, I suggest removing any hints about doing this because there is not enough bandwidth.

4. Section 1, paragraph two: "Streaming the media to the device addresses both the latency issue, since the client can start playing the media immediately..."
Who are we kidding here? There is no way to start playing without receiving data first. (Unless of course we play something else than what the user has asked for.)

5. Typo in Section 1, paragraph two: "A tradeoff" -> "A trade-off"

6. Section 1, paragrapth two: "A tradeoff is that the media cannot be viewed/played when the device is offline."
Unless of course it has been downloaded already (e.g. he user has viewed is once already so it's cached locally).

7. Wording change suggestion in Section 2.1, paragraph two:
"in order to accommodate the passing of a content transfer encoding parameter."
->
"in order to accommodate passing a content transfer encoding parameter."

8. Question regarding Figure 1: Shouldn't all arrows be double-headed?

9. Bullet 6. below figure 1:
"The media server or the client terminates the SIP session."
SIP session? I thought it would be RTP, MSRP, but SIP? SIP is not a transport protocol. Paragraph 1 in 2.4 says RTP.

10. Section 2.2 paragraph 1: "will be attempted" -> "is required"? I mean the next paragraph talks about it that way.

11. Section 2.2 paragraph 2: ";EXPIRE=<datetime>" Isn't there a "nicer" way to do this? This requires "funny" calculations on the client: current time (what if it's not valid?), current time zone (what if it's not valid), daylight saving setting (what if it's not valid)? A period (like: 1 hour period from now on) or an access count (like: 1 access attempt only) would be more comfy.

12. Section 2.2 paragraph 3: "the use of anonymous URLAUTH authorized URLs" shouldn't we disable anonymous access completely? It's an attachment in my email after all, which might very well contain strictly confidential info. I suspect that streaming will not be used when the smallest chance to leak info exists.

13. Section 2.2 paragraph 4: "SHOULD be 'authuser'" authuser being what? There is no info about this (not in syntax either). Also, I think that this should be a MUST and forbid anonymous access.

14. Extra space in section 2.3 paragraph 3: "pawn- ticket"

15. Wording change suggestion in 2.3 paragraph 3:
"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."
->
"For example, the client could discover a tuple of a media server address and an IMAP username, which allows the client to generate a secure URL that could *only* be accessed by a specific (presumably trusted) media server."

16. Same as comment #1 for the IANA registration in section 2.3: "Description: Defined in Streaming Multimedia Messaging Attachments" : remove the word "Messaging" - foe some it might mean MMS.

17. Typo (?) in 2.3 last paragraph: "left to the client implementor to decide" isn't is "implementer"?

18. Wording change suggestion in 2.4 paragraph 3:
"then if the client supports it,"
->
"but the client supports it,"

19. Wording change suggestion in 2.5 paragraph 4:
"Similarly, the message may well be encoded with a content transfer encoding such as base 64"
->
"Similarly, the message may be encoded with a content transfer encoding such as BASE64 [BASE64]"

20. Word missing in 2.5 second last paragraph: "If the receives a 200 OK response"

21. 2.5 last paragraph:
404 does not seem to be sufficient - a single status code covering all possible errors is not very useful. Is there any way to indicate to the client what very wrong (really)?

22. Wording change suggesion in 2.6 paragraph 1:
"it is felt worthwhile to give some examples "
->
"it is worth giving some examples"

23. Wording change suggestion in 2.6 paragraph 2:
"In the below example"
->
"In the example below"

24. Section 2.6, paragraph 3: "The client and server now know from the SDP advertised by both client and server that communication must be using the subset of audio
   codecs supported by both client and server (in the example SDP, it is clear that the server does not support any video codecs)."
I think they knew this without having to perform any communication - what they gain here is that they will both know the smallest common set.

25. Section 2.6 paragraph 4: "<playcollect> request" What is it? (No previous mentioning if this, at least a reference would be nice).

26. Wording change suggestion 2.7 paragraph 2: "establish" -> "discover".

27. Question on 2.7 paragraph 2: "must generate a SIP INFO request " shouldn't this be a MUST (upper-case)?

28. Question on 2.7 paragraph 4: shoudn't "playcollect" be always "<playcollect>"?

29. Wording change suggestion in 2.7 paragraph 12:
"The following gives an example dialog between"
->
"The following example shows a dialog between"

30. Question on Section 2.8 paragraph 2: Could we change that "SHOULD" to a "MUST"? Or, how will the IMAP server know the client policy? Same question for "SHOULD NOT"->"MUST NOT" in the next paragraph.

31. Typos in Section 3 paragraph 1: "INote that f one" -> "Note that one"

32. Typo (?) in section 3 paragraph 2: "implementors" -> "implementers"? I am not sure.

I did not review any of the examples.
Thanks for fixing.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

>-----Original Message-----
>From: ext Eric Burger [mailto:[email-masked]] 
>Sent: 22 March, 2007 01:54
>To: [email-masked]
>Subject: [lemonade] WGLC streaming - update
>
>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.
>

---

From: Dave Cridland <[email-masked]>
Date: Wed, 28 Mar 2007 11:56:19 +0000

Some meta-comments.

> 1. Title. Would it be OK to remove "Messaging" from the title? One 
Interesting point - maybe replace "Messaging" with "Internet Mail", 
perhaps?

> 2. Conventions: "The key words "MUST", "MUST NOT", "SHOULD", 
> "SHOULD NOT", and "MAY" in this document are to be interpreted as 
> defined in RFC 2119 [8]."
> Interestingly the list of these key words seems to vary from draft 
> to draft (take a look at draft-ietf-lemonade-rfc2192bis-04). Isn't 
> there a consolidated list that could be in every draft?
> 
> 
Yes, the correct boilerplate phrase is listed in RFC2119 itself.

> 11. Section 2.2 paragraph 2: ";EXPIRE=<datetime>" Isn't there a 
> "nicer" way to do this? This requires "funny" calculations on the 
> client: current time (what if it's not valid?), current time zone 
> (what if it's not valid), daylight saving setting (what if it's not 
> valid)? A period (like: 1 hour period from now on) or an access 
> count (like: 1 access attempt only) would be more comfy.
> 
> 
This is stipulated by URLAUTH, rather than this specification.

> 12. Section 2.2 paragraph 3: "the use of anonymous URLAUTH 
> authorized URLs" shouldn't we disable anonymous access completely? 
> It's an attachment in my email after all, which might very well 
> contain strictly confidential info. I suspect that streaming will 
> not be used when the smallest chance to leak info exists.
> 
> 
The general idea is that this allows arbitrary media servers to be 
used - how likely or desirable this is is a matter of opinion, but 
the mechanism exists. It doesn't grant "everyone" access, though, 
only "anyone" - that is, the specific entities that are given the 
anonymous URLAUTH authorized URLs.

> 13. Section 2.2 paragraph 4: "SHOULD be 'authuser'" authuser being 
> what? There is no info about this (not in syntax either).

Part of URLAUTH.

> 30. Question on Section 2.8 paragraph 2: Could we change that 
> "SHOULD" to a "MUST"? Or, how will the IMAP server know the client 
> policy? Same question for "SHOULD NOT"->"MUST NOT" in the next 
> paragraph.
> 
> 
That seems reasonable, but I suspect there's text in either URLAUTH 
or BURL which can be duplicated for both cases.

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: Neil Cook <[email-masked]>
Date: Thu, 29 Mar 2007 15:32:38 +0100

> streamed using RTP or RTSP.  SIP invites such.  Wordsmithing needed

Agreed!

> forward pointer to section 2.3x

Ok.

> corresponding CTE processing).

Hmm, I wouldn't like to specify the capabilities of a particular  
media server in the metadata, as that information could quickly go  
out of date, e.g. a media server could be upgraded to support new  
media types and the IMAP server would not necessarily (imo almost  
certainly not) be updated with that new information.

The issue is not that media server vendors wouldn't want to implement  
IVR to be LEMONADE compliant, the issue is more about how to  
discover, without "fishing" as you put it, the capabilities of a set  
of LEMONADE compliant media servers from a LEMONADE compliant IMAP  
server. I would assert that static configuration is bad, in fact  
potentially worse than fishing.

In my experience, although the document gives the example of an audio- 
only media server as an example to show how negotiation could be  
done, in practice all the media servers I have worked with in the  
recent past actually support a wide range of audio and video codecs.

> client-server BW savings.

IMAP URL doesn't support binary fetch. If it did I would be happy.

> know if this needs a fix, but it needs a mention in section 3.

I will mention it. I think if you get the media server identity from  
the IMAP server then there is implicit trust. Otherwise, the media  
server is configured by out of band means, and I have no way to  
determine the security or otherwise of such a method, other than to  
mention it.

> fetched by the media server.  Such solutions don't require any  

I will re-work the DRM discussion. Further comments on suggested text  
are welcome, as it is not a particular area of expertise for me.

Neil.

---

From: Neil Cook <[email-masked]>
Date: Thu, 29 Mar 2007 16:02:50 +0100

> 1. Title. Would it be OK to remove "Messaging" from the title? One  

I could just replace "Messaging" with "Email".

> there a consolidated list that could be in every draft?

Yes, I thought I had copied verbatim from RFC2119 but obviously not.  
I will correct.

> 3. Section 1, paragraph one: "Email clients on resource and/or  
> network constrained devices, such a mobile phones, may have  
> difficulties in retrieving and/or storing large attachments  
> received in a message. For example, on a poor network link, the  
> latency required to download the entire attachment may not be  
> acceptable to the user."

Ok.

> I am not sure how streaming helps network contstrained devices  
> since streaming might be more network-demanding in some cases than  
> a slow fetch. I thought the whole reason of doing streaming was:  
> not to download and store stream-able attachments at all. I've seen  
> streaming on slow networks, and I can tell that I would rather wait  
> longer to retrieve it slowly in the background without streaming.  
> Looking at the phone and waiting for new frames to be drawn is  
> just: bad. Even today, in my office where there is gigabits of  
> bandwidth I still have to wait for some streams for pre-load more  
> than half of the movies (not because there is a network limit, not  
> because there is a client limit, but because there are limitations  
> on the server.) Therefore, I suggest removing any hints about doing  
> this because there is not enough bandwidth.

I'm not sure I agree. There are plenty of scenarios where streaming  
is more network efficient. If someone sends me a very high definition  
movie or audio clip, but that clip is streamed to my device rather  
than retrieved, I can watch/listen to it in a fraction of the time it  
would have taken to download it, because streaming almost always  
means transcoding to a lower quality suitable for the device.

> 4. Section 1, paragraph two: "Streaming the media to the device  
> addresses both the latency issue, since the client can start  
> playing the media immediately..."
> Who are we kidding here? There is no way to start playing without  
> receiving data first. (Unless of course we play something else than  
> what the user has asked for.)

I will change "immediately" to "shortly".

> 5. Typo in Section 1, paragraph two: "A tradeoff" -> "A trade-off"

Both are acceptable, at least in UK English.

> 6. Section 1, paragrapth two: "A tradeoff is that the media cannot  
> be viewed/played when the device is offline."
> Unless of course it has been downloaded already (e.g. he user has  
> viewed is once already so it's cached locally).

I will change "cannot" to "may not be able to". Due to resource or  
other constraints, the device may not be able to cache the media.

Ok.

> 8. Question regarding Figure 1: Shouldn't all arrows be double-headed?

Theoretically yes, but I hoping to make initiation implicitly clear.

> SIP session? I thought it would be RTP, MSRP, but SIP? SIP is not a  
> transport protocol. Paragraph 1 in 2.4 says RTP.

You're right. Will change to "terminates the media session".

> 10. Section 2.2 paragraph 1: "will be attempted" -> "is required"?  
> I mean the next paragraph talks about it that way.
>
Ok.

> what? There is no info about this (not in syntax either). Also, I  
> think that this should be a MUST and forbid anonymous access.
>
Answered by Dave Cridland already.

Ok.

> "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."
> ->
> "For example, the client could discover a tuple of a media server  
> address and an IMAP username, which allows the client to generate a  
> secure URL that could *only* be accessed by a specific (presumably  
> trusted) media server."

Ok. Will be changing this section anyway, as "IMAP username" is wrong.

> 16. Same as comment #1 for the IANA registration in section 2.3:  
> "Description: Defined in Streaming Multimedia Messaging  
> Attachments" : remove the word "Messaging" - foe some it might mean  
> MMS.

WIll change to Email.

Ok.

> "but the client supports it,

ok.

> encoding such as BASE64 [BASE64]"

Will reference.

> 20. Word missing in 2.5 second last paragraph: "If the receives a  

Will fix.

> 21. 2.5 last paragraph:
> 404 does not seem to be sufficient - a single status code covering  
> all possible errors is not very useful. Is there any way to  
> indicate to the client what very wrong (really)?

Theoretically the media server could return a number of SIP error  
code, but this document doesn't attempt to cover all of them. It just  
explains what that particular error code means.

> "it is worth giving some examples"

ok

> 23. Wording change suggestion in 2.6 paragraph 2:

ok

> 24. Section 2.6, paragraph 3: "The client and server now know from  
> the SDP advertised by both client and server that communication  
> must be using the subset of audio
>    codecs supported by both client and server (in the example SDP,  
> it is clear that the server does not support any video codecs)."
> I think they knew this without having to perform any communication  
> - what they gain here is that they will both know the smallest  
> common set.

Will wordsmith.

> 25. Section 2.6 paragraph 4: "<playcollect> request" What is it?  
> (No previous mentioning if this, at least a reference would be nice).

This is part of MSCML RFC. Will reference.

> 26. Wording change suggestion 2.7 paragraph 2: "establish" ->  

ok

> " shouldn't this be a MUST (upper-case)?
Yep.

> 28. Question on 2.7 paragraph 4: shoudn't "playcollect" be always  
Probably, yes :)

> "The following example shows a dialog between"
ok.

> policy? Same question for "SHOULD NOT"->"MUST NOT" in the next  

I think that would be okay.

Ok.

> "implementers"? I am not sure.

I think both are valid.

Neil.

---

From: Mark Crispin <[email-masked]>
Date: Thu, 29 Mar 2007 09:30:15 -0700 (PDT)

> I could just replace "Messaging" with "Email".

That's no good.  We switched from "mail" to "messaging" in IMAP's name for 
a reason; IMAP encompasses news as well as email.  That is a far more 
serious possibility of confusion.

Suggest "Internet Messaging" if you want to exclude MMS.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Mark Crispin <[email-masked]>
Date: Thu, 29 Mar 2007 09:33:04 -0700 (PDT)

> Suggest "Internet Messaging" if you want to exclude MMS.

And, since IMAP is the "Internet Message Access Protocol" you have a 
precedent for the term.

-- Mark --

http://panda.com/mrc

---

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

Sounds good,

thanks,

Neil.

On 29 Mar 2007, at 17:33, Mark Crispin wrote:

> And, since IMAP is the "Internet Message Access Protocol" you have  
> a precedent for the term.
>
> -- Mark --
>
> http://panda.com/mrc

---

From: <[email-masked]>
Date: Fri, 30 Mar 2007 10:47:07 +0300

Neil,
I have some comments vs. Yours.

>> 3. Section 1, paragraph one: "Email clients on resource..:"
>> I am not sure how streaming helps network contstrained devices since 
>> streaming might be more network-demanding in some cases than a slow 
>> fetch. I thought the whole reason of doing streaming was:
>> bandwidth I still have to wait for some streams for pre-load 
>more than 
>> half of the movies (not because there is a network limit, 
>not because 
>> there is a client limit, but because there are limitations on the 
>> server.) Therefore, I suggest removing any hints about doing this 
>> because there is not enough bandwidth.

>I'm not sure I agree. There are plenty of scenarios where 
>streaming is more network efficient. If someone sends me a 
>very high definition movie or audio clip, but that clip is 
>streamed to my device rather than retrieved, I can 
>watch/listen to it in a fraction of the time it would have 
>taken to download it, because streaming almost always means 
>transcoding to a lower quality suitable for the device.

Hmm, yes. But then I have to say that I do not know what You mean by
constrained network. I've never seen a clip played without hickups - and
in some cases I did not even want to watch it: having to wait 1-5secs
for a few frames to arrive (video looks like a slideshow). I think
streaming saves sudden spikes in bandwidth (a more balanced network
utilization): download all vs. download frame-by-frame.
But I guess arguing over this is not worth our time since it's not a
major issue.

>Theoretically yes, but I hoping to make initiation implicitly clear.

Could we decribe this fact somehow? (To aviod questions like mine.)

>> 21. 2.5 last paragraph:
>> 404 does not seem to be sufficient - a single status code 
>covering all 
>> possible errors is not very useful. Is there any way to indicate to 
>> the client what very wrong (really)?
>
>Theoretically the media server could return a number of SIP 
>error code, but this document doesn't attempt to cover all of 
>them. It just explains what that particular error code means.

It is more like an example then, right?

Thank You Neil!