Subject: [lemonade] Extend URLAUTH to fetch MIME data for bodyparts?

From: Neil Cook <[email-masked]>
Date: Thu, 10 May 2007 09:32:51 +0100

All,

the current version of the streaming draft has got a problem, in  
that, given a piece of MIME content stored in a message, and an IMAP  
URL to that bodypart that must be retrieved using URLFETCH, the  
client given the URL does not know:

1) The Content-Type  of the bodypart to be fetched
2) The Content-Transfer-Encoding of the bodypart to be fetched

To fix this entails the streaming draft recommending updates to two  
other RFCs (4240 and 4722) which specify the ability to pass Content- 
Type and Content-Transfer-Encoding data to media servers supporting  
these protocols.

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.

This could be an option to the existing URLFETCH command, e.g.

a1 MIME URLFETCH "imap://[email-masked]/INBOX/;uid=20/
          ;section=1.2;urlauth=submit+fred:internal
          :91354a473744909de610943775f92038"

That would return the MIME headers associated with that bodypart  
along with the bodypart itself.

or, perhaps better, to create a new command that retrieve only the  
MIME data associated with the bodypart, e.g.

a2 URLFETCHMIME "imap://[email-masked]/INBOX/;uid=20/
          ;section=1.2;urlauth=submit+fred:internal
          :91354a473744909de610943775f92038"

I think this would be generally useful in the future to other  
applications that make use of URLAUTH, as it cannot be presumed that  
they know in advance the content-type or c-t-e when they have just  
been passed an IMAP URL.

Comments?

Neil.

_______________________________________________
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: Thu, 10 May 2007 09:51:56 +0100

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: 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:

> 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.
>
> urlfetch-data = "*" SP "URLFETCH" 1*(SP url-simple [SP "(" url- 
> additional SP stuff ")"]
> 		SP nstring)
>
> 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.
> --

---

From: Dave Cridland <[email-masked]>
Date: Thu, 10 May 2007 12:25:25 +0100

On Thu May 10 12:05:24 2007, Neil Cook wrote:
> Presumably if you did the fetch without specifying binary, you'd 
> get  the CTE in the BODYSTRUCTURE,and could thus decode it manually?
> 
> 
Probably we could define that, yes. To be honest, I'd be inclined to 
aim for just type information, and tell people to use BINARY.

The alternative would be to wrap up the binary into the URI, but I 
don't see the need - I think it's quite complex enough to parse IMAP 
URIs without making life even harder for us.

Something that might be worthwhile would be allowing CATENATE and 
BURL to handle additional directives. That and a CONVERT-like 
directive would allow clients to construct multipart/alternative 
messages quite easily.

> 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.
> 
> 
I was under the impression that HTTP doesn't have CTE, technically - 
it has TE, which is different. Transfer-Encoding is usually payload 
compression, whereas Content-Transfer-Encoding is solely to make 
things fit into a (possibly 7-bit) text domain.

Dave.

---

From: Neil Cook <[email-masked]>
Date: Mon, 14 May 2007 10:48:15 +0100

Thanks Dave,

You're right about HTTP TE, but of course HTTP may contain MIME  
parts, however I think practice there isn't that much CTE in HTTP.

Anyway, do you know what the next step is? How do I formally propose  
that we update URLAUTH with this new functionality?

Neil.

On 10 May 2007, at 12:25, Dave Cridland wrote:

> Probably we could define that, yes. To be honest, I'd be inclined  
> to aim for just type information, and tell people to use BINARY.
>
> don't see the need - I think it's quite complex enough to parse  
> IMAP URIs without making life even harder for us.
>
> I was under the impression that HTTP doesn't have CTE, technically  
> - it has TE, which is different. Transfer-Encoding is usually  
> payload compression, whereas Content-Transfer-Encoding is solely to  
> make things fit into a (possibly 7-bit) text domain.
>
> Dave.
> --

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 14 May 2007 13:14:01 +0100

> that we update URLAUTH with this new functionality?

Somebody needs to write a new (short) draft extending URLAUTH. Any 
volunteers?