[lemonade] WGLC streaming Comments

["Vaudreuil, Greg M \(Greg\)" <gregv at alcatel-lucent.com>]

Resending... The policy filter ate my message.

Greg V.


2nd paragraph of section 1.  SIP does not stream media!  Meda can be
streamed using RTP or RTSP.  SIP invites such.  Wordsmithing needed

text following figure 1.

Bullet 0 should make it clear how the client knows whether there is a
media server and whether the media can be streamed.   Maybe just a
forward pointer to section 2.3x

General comment.  I'm not comfortable with the amount of "go fish" in
the protocol.  The server is not required to support both IVR and NETANN
protocols, so the client is instructed to first try one, and if it
fails, then try the other protocol.  Further, the client given a choice
of separate audio and video media servers (for example) may have to play
go fish across the set.  It would be better to specify at some useful
level (top-level content-type would be sufficient for my needs) the
capabilities of the media server in the IMAP metadata, and to require
the superset IVR service.     Is the idea that media server vendors
don't want to implement IVR to be LEMONADE compliant?  They already have
a bunch of work to support IMAP and the expanded SIP headers (and
corresponding CTE processing). 

Content-transfer-encoding.  I should be more up-to-date on IMAP
binary... I don't have a version in my cache and this is an airplane
message.  But could we not simplify things by requiring the media server
to always use a binary fetch and requring the IMAP server to strip the
CTE to binary?  Saves a SIP extension and teaching media servers about
CTE.  IMAP server already has to do binary for LEMONADE... My memory
suggests we required the ability for the server to unwrap CTE's for
client-server BW savings.

Section 3.  

Why should a client trust a particular media server? "Bad news, your lab
results show you are....."   The client authenticates to the submission
server, so there is some reasonable expectation that the server is
authorized to see message content.  There does not seem to be any
equivalent for the media server.  Maybe there is more trust if you found
the media server identity in METADATA from the IMAP server?  I don't
know if this needs a fix, but it needs a mention in section 3.

Section 4.

This discussion seems to be limited to Forward-Lock DRM.  Crypto-based
DRM may use separate solutions that are between the media server and the
client, where the client provides necessary gunk to unlock the blob
fetched by the media server.  Such solutions don't require any extension
to URLAUTH.



Greg V.

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