[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