[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lemonade] WGLC streaming - update; comments
On 28 Mar 2007, at 10:50, <Zoltan.Ordogh at nokia.com>
<Zoltan.Ordogh at nokia.com> wrote:
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.
I could just replace "Messaging" with "Email".
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, 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."
Typo: "such a" -> "such as"
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.
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."
Ok.
8. Question regarding Figure 1: Shouldn't all arrows be double-headed?
Theoretically yes, but I hoping to make initiation implicitly clear.
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.
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.
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.
Answered by Dave Cridland already.
14. Extra space in section 2.3 paragraph 3: "pawn- ticket"
Ok.
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."
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.
17. Typo (?) in 2.3 last paragraph: "left to the client implementor
to decide" isn't is "implementer"?
Ok.
18. Wording change suggestion in 2.4 paragraph 3:
"then if the client supports it,"
->
"but the client supports it,
ok.
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]"
Will reference.
20. Word missing in 2.5 second last paragraph: "If the receives a
200 OK response"
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.
22. Wording change suggesion in 2.6 paragraph 1:
"it is felt worthwhile to give some examples "
->
"it is worth giving some examples"
ok
23. Wording change suggestion in 2.6 paragraph 2:
"In the below example"
->
"In the example below"
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" ->
"discover".
ok
27. Question on 2.7 paragraph 2: "must generate a SIP INFO request
" shouldn't this be a MUST (upper-case)?
Yep.
28. Question on 2.7 paragraph 4: shoudn't "playcollect" be always
"<playcollect>"?
Probably, yes :)
29. Wording change suggestion in 2.7 paragraph 12:
"The following gives an example dialog between"
->
"The following example shows a dialog between"
ok.
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.
I think that would be okay.
31. Typos in Section 3 paragraph 1: "INote that f one" -> "Note
that one"
Ok.
32. Typo (?) in section 3 paragraph 2: "implementors" ->
"implementers"? I am not sure.
I think both are valid.
Neil.
_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade