Subject: [lemonade] Rounding Final Lap

From: Eric Burger <[email-masked]>
Date: Mon, 09 Jul 2007 17:09:12 -0400

Folks - we are almost there!  The end is in sight!

I have put up a web page listing the status of *active* drafts.  An active
draft is a draft that is still in our control.  That is, it is NOT in the
RFC Editor Queue, not in IESG processing, and not dead.

By my count, we have 9-10 documents to go.  Of those documents, two just got
to the IESG, three are pretty much done, and four are being worked on in
earnest.  For those who can add to ten, the tenth document is possibly an
IMAP URL extension for support of the streaming document.

Since we are so close, I will try to manually keep score on-line.  Check
out:

http://www.standardstrack.com/ietf/lemonade/active-status.html

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Dave Cridland <[email-masked]>
Date: Tue, 10 Jul 2007 10:29:58 +0100

> IMAP URL extension for support of the streaming document.

Mea culpa.

I'll sketch out a draft to do this in time for the meeting, based on 
stuff I've posted to this list. I'm pretty sure that Philip had 
something to say on that, but I've forgotten what it was. A reminder 
for my failing memory would be most welcome.

Basically, I'm going to add syntactic glue to be able to make 
URLFETCH provide a BODYPARTSTRUCTURE (From CONVERT) and provide the 
result in an identity CTE. This will allow for both Neil Cook's 
streaming stuff to work, and also URLAUTH-signed conversion 
requesting URIs. How evil of me.

Attached is Neil's reply to my suggestion, so you can avoid digging 
in your archives. (Message assembled using CATENATE, and then sent 
via BURL/URLAUTH, of course - my, this dogfood is tasty).

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Subject: Re: [lemonade] Extend URLAUTH to fetch MIME data for bodyparts?
From: Neil Cook <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: Enhancements to Internet email to support diverse service enivronments <[email-masked]>
Date: Thu, 10 May 2007 12:05:24 +0100

Dave,

that seems reasonable to me.

Presumably if you did the fetch without specifying binary, you'd get  
the CTE in the BODYSTRUCTURE,and could thus decode it manually?

BTW, I think media servers are probably already used to dealing with  
CTE, as they  can already handle HTTP URLs, which may or may not  
refer to c-t-e content. However, being able to download the content  
without CTE is definitely a big plus imo.

Neil.

On 10 May 2007, at 09:51, Dave Cridland wrote:

> On Thu May 10 09:32:51 2007, Neil Cook wrote:
>> Now there has been a small amount of discussion in this group on  
>> how  to achieve that without updating those protocols. I've been  
>> thinking  about it, and it seems to me that the best (and most  
>> generic) fix  would be to update the URLAUTH RFC to include an  
>> option that  specifies that the MIME data associated with the  
>> bodypart should be  returned.
> You can, of course, pass a URL to the MIME header of the part.  
> That's doable, but it means passing two URLs to the consumer.
>
> Otherwise, I'd personally be more interested in decoding the CTE at  
> source (like BINARY does), and then appending a BODYSTRUCTURE  
> fragment (or similar) describing MIME headers.
>
> For example:
>
> url-full = url-simple / url-extended
> 	; Changed from RFC4467
> url-simple = astring
> 	; Containing authimapurlfull
> url-extended = "(" url-simple *(SP url-additional) ")"
> url-additional = "STRUCTURE" / "BINARY" / iana-token
> urlfetch-data = "*" SP "URLFETCH" 1*(SP url-simple [SP "(" url- 
> additional SP stuff ")"]
> 		SP nstring)
>
> Now we have the syntactic glue, we can do:
>
> C: D01 URLFETCH ("imap://[...]" STRUCTURE BINARY)
> S: * URLFETCH "imap://[...]" (STRUCTURE ("audio" "mp3" [...])) {~1234}
> S: [1234 octets of binary data, containing NUL octets]
> S: D01 OK Completed
>
> Does this seem reasonable? I think it gets the streaming servers  
> what they need (and at lower impact, since presumably they never  
> had to deal with CTE before).
>
> Dave.
> -- 
> Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
>  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>  - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>
>

---

From: Neil Cook <[email-masked]>
Date: Tue, 10 Jul 2007 17:43:08 +0100

Thanks Dave,

I will update the streaming draft before the meeting based on the  
summary below. This removes the need for additional SIP parameter  
registration etc., and generally makes the draft cleaner.

Neil.

On 10 Jul 2007, at 10:29, Dave Cridland wrote:

> I'll sketch out a draft to do this in time for the meeting, based  
> on stuff I've posted to this list. I'm pretty sure that Philip had  
> something to say on that, but I've forgotten what it was. A  
> reminder for my failing memory would be most welcome.
>
> Date: 10 May 2007 12:05:24 BDT
> Presumably if you did the fetch without specifying binary, you'd  
> get the CTE in the BODYSTRUCTURE,and could thus decode it manually?
>
> BTW, I think media servers are probably already used to dealing  
> with CTE, as they  can already handle HTTP URLs, which may or may  
> not refer to c-t-e content. However, being able to download the  
> content without CTE is definitely a big plus imo.
>
> Neil.
>
>> Otherwise, I'd personally be more interested in decoding the CTE  
>> at source (like BINARY does), and then appending a BODYSTRUCTURE

---

From: <[email-masked]>
Date: Sat, 21 Jul 2007 22:17:52 +0300

The scoreboard is a good idea.
Thanks.

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

>-----Original Message-----
>From: ext Eric Burger [mailto:[email-masked]] 
>Sent: 10 July, 2007 00:09
>To: [email-masked]
>Subject: [lemonade] Rounding Final Lap
>
>I have put up a web page listing the status of *active* 
>drafts.  An active draft is a draft that is still in our 
>control.  That is, it is NOT in the RFC Editor Queue, not in 
>IESG processing, and not dead.
>
>By my count, we have 9-10 documents to go.  Of those 
>documents, two just got to the IESG, three are pretty much 
>done, and four are being worked on in earnest.  For those who 
>can add to ten, the tenth document is possibly an IMAP URL 
>extension for support of the streaming document.
>
>Notice:  This email message, together with any attachments, 
>may contain information  of  BEA Systems,  Inc.,  its 
>subsidiaries  and  affiliated entities,  that may be 
>confidential,  proprietary,  copyrighted  and/or legally 
>privileged, and is intended solely for the use of the 
>individual or entity named in this message. If you are not the 
>intended recipient, and have received this message in error, 
>please immediately return this by email and then delete it.
>
>