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

Re: [lemonade] WGLC streaming

I've skimmed the document, too.

On Tue Mar 27 11:18:41 2007, Alexey Melnikov wrote: 
Eric Burger wrote:

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.

The document is in a pretty good shape. However examples contain several minor bugs and there are also some issues with IANA registrations as well as with Normative References. My detailed comments are below:

1). Almost all IMAP examples use trailing '\' to specify line
continuations (and the examples don't use them consistently). This is
unusual for IMAP and not specified in the conventions. I suggest just
removing them.


Yes, this would be good.


2). In Section 2.2:





The first example:

  C: a122 UID FETCH 24356 BODY[1.2.MIME]
  S: * 26 FETCH (BODY[1.2.MIME] {127}
  S: Content-Transfer-Encoding: base64
  S: Content-Type: video/mpeg;
  S: UID 24356 FLAGS (\Seen))


Should be:

  C: a122 UID FETCH 24356 BODY[1.2.MIME]
  S: * 26 FETCH (BODY[1.2.MIME] {62}
  S: Content-Transfer-Encoding: base64
  S: Content-Type: video/mpeg;
  S:  UID 24356 FLAGS (\Seen))

(i.e. an extra space before "UID" and change "{127}" to "{62}"


Actually, no... It *should* be using BODYSTRUCTURE to find the media type - by the time you know that section 1.2 (or 1.2.MIME) exists, you already know the media type of the part, and its encoding.

3). In section 2.3

Clients SHOULD parse the value of mediaServers, (using either the
value.priv or value.shared: whichever is available and/or
appropriate), and contact a media server using one of the supplied
values. No particular preference order is implied by the ordering,

I would prefer is the order specified by the server is the preferred order.


I'm not sure it matters overmuch. It might be that the client can identify which server is closest better than the server. It really depends upon what we mean by "preferred".

Similarly, the message may well be encoded with a content transfer
encoding such as base 64. However, RFC 4240 does not include a
method for communicating content transfer encoding to the media
server as part of the announcement service, nor does the URLFETCH
command include a mechanism for retrieving message parts without
encoding (c.f. the BINARY [17] extension to IMAP).

Would it be better if IMAP URL is extended to allow for binary content
fetching?


I think that might well be neater, although it depends on which extension requires more work.

7). Flow diagrams in section 2.9 don't show IMAP responses. This might
be Ok.


I think it'd be clearer if they were there. (Again, this is FETCH BODY[MIME], rather than FETCH BODYSTRUCTURE).

9). In section 5: 


I think this should be:

  ms-tuple = host ":" port [":" "authuser"]

as the last component is optional.


I'm concerned with IPv6 behaviour with this production. I'm also thinking that perhaps a URI form would be more suitable, as it allows for more expansion capability. Assuming, that is, that these media services have URIs to them.

10). There is no "IANA Considerations" section. One should be added and
contain text about a METADATA annotation registration, as well as the
registration of new SIP, etc. parameters.


The Metadata annotation registration is in 2.3, but yes, it needs to be moved.

Further comments - and please note that the majority of the SIP stuff goes shooting over my head:

In the Security Considerations section, there seems to be a sudden lack of references. In particular, sips, SIP, RFC4240, RFC4722, and S/MIME all lack references (although they're in the Normative References section).

The IMAP base specification, and URLAUTH, also has recommendations concerning encryption layers in conjunction with authorized URLs - you may find it better to simply include the security considerations in both RFC3501 and URLAUTH by reference. Typically, you'd do this with this text replacing the first two paragraphs:

"This document proposes the use of URLAUTH [URLAUTH] "pawn tickets", received over IMAP [IMAP], and transmitted over SIP [SIP], possibly within the MSCML payload of IVR [RFC4722]. As such, the security considerations in all these documents apply to this specification.

In summary, as the authorized URLs may grant access to data, implementors of this specification need to consider the following:"

Or something similar, anyway.

Section 4: The Great DRM Can Of Worms:

If I were a lawyer, then aside from the fact I'd never read a technical document, I'd be concerned with the phrase "[...] also implicitly gives the creator [of the URLAUTH authorized URL] the right to pass that reference on to any third party it desires." This phrase implies that the document authors believe that transmission of media via email grants the recipient rights to redistribution, which is probably not the view of most people, DRM-fans or not.

Without delving into the precise legal terminology required, I'd say that the use of URLAUTH in this specification is believed to be persuant with, and used only for, the execution of those rights to be expected when media is sent via traditional internet messaging, and causes no duplication of media content which is not essentially provided by the action of sending the message; that is, the use of the content for downloading and viewing, which *is* implicitly granted by the sender of the message, in as much as the sender has the right to grant such rights.

I might also state that any DRM required needs to be implemented within the media type, and moreover to take into account that the use of this specification requires a third party to access the media content in order to provide efficient private streaming.

I'm very much against implementing DRM checks in URLAUTH, which would require me to maintain a somehow perfect list of media types which require DRM checks, and presumably open my employer to DRM related lawsuits should I fail to comply.

As a final comment, I believe this specification needs careful review by a suitable working group (or groups) within the SIP community - could I suggest that the Chairs, or Secretary, arrange this with the RAI review team, or RAI ADs?

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