Subject: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt

From: "Burger, Eric" <[email-masked]>
Date: Tue, 13 Jun 2006 05:00:58 -0400

I would offer that we just state DRM is up to the IMAP server.  It is way beyond lemonade scope to figure out and replicate full DRM.  Rather, let's do butt simple DRM: if the client has the right to copy an object, they can do whatever they want with it.  The implementation is in URLAUTH.  If you cannot copy an object, for whatever reason, determined way outside the protocol, the server will not generate a URLAUTH token.  The converse holds, as well.  If the server generates a URLAUTH token, the client can do whatever it wants with the object.  The client can forward the object (BURL), stream the object (streaming), or eat the object (URLFETCH).  We should explicitly say that (1) this provides greater than or equal to DRM semantics with respect to existing e-mail and (2) if you want real DRM, implement a real DRM system.

Comments?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 08, 2006 4:31 AM
To: [email-masked]
Subject: RE: [lemonade] draft-cook-lemonade-streaming-00.txt

I think it's looking good and simple: we generate a URL withing the IMAP session for the media, then client connects directly to media server to start streaming.
Comments/questions:
 - URLAUTH is RFC 4467 now, not a draft, so the reference should be updated.
 - There is no mentioning of DRM. Should there be? Has it been considered at all? Or we do not need to because we leave it up to the client and the media server to sort it out? Can an IMAP server create an authorized URL for a DRMed content without any problem? (I'm not an expert on DRM, but I do know that it has been problematic in other messaging systems).
Thank You, a good draft once again.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

-----Original Message-----
From: ext Burger, Eric [mailto:[email-masked]] 
Sent: 31 May, 2006 03:48
To: Enhancements to Internet email to support diverse serviceenivronments
Subject: [lemonade] draft-cook-lemonade-streaming-00.txt

Until it hits the archives, here is a copy of the outline for the streaming services draft.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Neil Cook <[email-masked]>
Date: Wed, 14 Jun 2006 18:39:53 +0100

Eric,

I agree. If there's no objections, I'll put some verbage  
incorporating the below comments in the next draft.

Neil.

On 13 Jun 2006, at 10:00, Burger, Eric wrote:

> I would offer that we just state DRM is up to the IMAP server.  It  
> is way beyond lemonade scope to figure out and replicate full DRM.   
> Rather, let's do butt simple DRM: if the client has the right to  
> copy an object, they can do whatever they want with it.  The  
> implementation is in URLAUTH.  If you cannot copy an object, for  
> whatever reason, determined way outside the protocol, the server  
> will not generate a URLAUTH token.  The converse holds, as well.   
> If the server generates a URLAUTH token, the client can do whatever  
> it wants with the object.  The client can forward the object  
> (BURL), stream the object (streaming), or eat the object  
> (URLFETCH).  We should explicitly say that (1) this provides  
> greater than or equal to DRM semantics with respect to existing e- 
> mail and (2) if you want real DRM, implement a real DRM system.
>
> Comments?
>
> I think it's looking good and simple: we generate a URL withing the  
> IMAP session for the media, then client connects directly to media  
> server to start streaming.
> Comments/questions:
>  - There is no mentioning of DRM. Should there be? Has it been  
> considered at all? Or we do not need to because we leave it up to  
> the client and the media server to sort it out? Can an IMAP server  
> create an authorized URL for a DRMed content without any problem?  
> (I'm not an expert on DRM, but I do know that it has been  
> problematic in other messaging systems).

---

From: <[email-masked]>
Date: Tue, 20 Jun 2006 13:04:57 +0300

No comments, sounds reasonable.
Should we capture it in the draft one way or another to aviod these questions in the future?
Thank You. 

-----Original Message-----
From: ext Burger, Eric [mailto:[email-masked]] 
Sent: 13 June, 2006 12:01
To: Ordogh Zoltan (Nokia-TP-MSW/Tampere)
Cc: [email-masked]
Subject: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt

Comments?

---

From: Neil Cook <[email-masked]>
Date: Tue, 20 Jun 2006 15:42:42 +0100

I just submitted a new version of the draft that encapsulates these  
comments, please let me know what you think.

Neil.

---

From: <[email-masked]>
Date: Wed, 21 Jun 2006 13:18:39 +0300

Mea culpa: I was looking at draft-cook-lemonade-streaming-00.txt instead of draft-ietf-lemonade-streaming-00.txt.
The updated version is great, thank You.

-----Original Message-----
From: ext Neil Cook [mailto:[email-masked]] 
Sent: 20 June, 2006 17:43
To: Ordogh Zoltan (Nokia-TP-MSW/Tampere)
Cc: [email-masked]; [email-masked]
Subject: Re: DRM and RE: [lemonade] draft-cook-lemonade-streaming-00.txt

I just submitted a new version of the draft that encapsulates these comments, please let me know what you think.

Neil.

On 20 Jun 2006, at 11:04, <[email-masked]> <[email-masked]> wrote:

> Rather, let's do butt simple DRM: if the client has the right to copy 
> an object, they can do whatever they want with it.  The implementation 
> is in URLAUTH.  If you cannot copy an object, for whatever reason, 
> determined way outside the protocol, the server
> If the server generates a URLAUTH token, the client can do whatever it 
> wants with the object.  The client can forward the object (BURL), 
> stream the object (streaming), or eat the object (URLFETCH).  We 
> should explicitly say that (1) this provides greater than or equal to 
> DRM semantics with respect to existing e- mail and (2) if you want 
> real DRM, implement a real DRM system.
>
> Comments?
>
> considered at all? Or we do not need to because we leave it up to the 
> client and the media server to sort it out? Can an IMAP server create 
> an authorized URL for a DRMed content without any problem?
> (I'm not an expert on DRM, but I do know that it has been problematic 
> in other messaging systems).