Re: [lemonade] Rounding Final Lap

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:

> On Mon Jul  9 22:09:12 2007, Eric Burger wrote:
>> earnest.  For those who can add to ten, the tenth document is  
>> possibly an
>> 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:dave@cridland.net - xmpp:dwd@jabber.org
>  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>  - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>
> From: Neil Cook <neil.cook@noware.co.uk>
> Date: 10 May 2007 12:05:24 BDT
> To: Dave Cridland <dave@cridland.net>
> Cc: Enhancements to Internet email to support diverse service  
> enivronments <lemonade@ietf.org>
> Subject: Re: [lemonade] Extend URLAUTH to fetch MIME data for  
> bodyparts?
>
>
> 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:dave@cridland.net - xmpp:dwd@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@ietf.org
>> https://www1.ietf.org/mailman/listinfo/lemonade
>> Supplemental Web Site:
>> http://www.standardstrack.com/ietf/lemonade
>>
>
>
>
> _______________________________________________
> lemonade mailing list
> lemonade@ietf.org
> https://www1.ietf.org/mailman/listinfo/lemonade
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/lemonade

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