[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [lemonade] WGLC streaming - update; comments
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:eburger at bea.com]
>Sent: 22 March, 2007 01:54
>To: lemonade at ietf.org
>Subject: [lemonade] WGLC streaming - update
>
>This is the announcement for the Work Group Last Call on the
>Streaming Media
>draft:
>http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streami
>ng-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
>lemonade at ietf.org
>https://www1.ietf.org/mailman/listinfo/lemonade
>Supplemental Web Site:
>http://www.standardstrack.com/ietf/lemonade
>
_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade