Re: [lemonade] Rounding Final Lap

[Dave Cridland <[e-mail]>]

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:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

--- Begin Message ---

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:[e-mail] - xmpp:[e-mail]
>  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>  - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>
>
> _______________________________________________
> lemonade mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/lemonade
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/lemonade
>

--- End Message ---

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