[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lemonade] WGLC streaming - update; comments



Some meta-comments.

On Wed Mar 28 10:50:10 2007, 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.



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:dave at cridland.net - xmpp:dwd at jabber.org
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade