Subject: RE: [lemonade] partial fetches with IMAP URLs?

From: [email-masked]
Date: Tue, 23 Nov 2004 08:36:57 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext Mark Crispin
> Sent: Monday, November 22, 2004 10:56 PM
...
> On Mon, 22 Nov 2004, Pete Resnick wrote:
> > There was discussion not too long ago that IMAPURL needed 
> to be updated 
> > anyway. Adding byte-ranges to the URL would get them into 
> URLFETCH, BURL, and 
> > CATENATE by reference automatically.
> 
> Actually, not; since the byte-range would be determined by 
> whatever entity 
> generated the URL, whereas the need is for the entity that is 
> fetching the 
> data.

The syntax could allow the range to be appended after the fetching
entity received it. URLAUTH would have to allow for the URL to 
extend beyond "URLAUTH=<access>:<mech>:<token>". The token would 
only authorize the rump, and would tolerate the range syntax.

Mike

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

---

From: Eric Burger <[email-masked]>
Date: Tue, 23 Nov 2004 09:48:31 -0500

What if I had a URLAUTH over an imap: URL?  If I hack the byte range, won't
that hack the signature.  Also, what about error conditions, like fetching
beyond the end of the object or across the end of the object?

> From: Philip Guenther [mailto:[email-masked]]
> Sent: Monday, November 22, 2004 11:29 PM
> To: Pete Resnick
> Cc: [email-masked]
> Subject: Re: [lemonade] partial fetches with IMAP URLs? 
> 
> 
> Pete Resnick <[email-masked]> writes:
> >On 11/22/04 at 1:59 PM -0800, Philip Guenther wrote:
> >>IMAP URLs, like HTTP URLs, do not provide a syntax for specifying a 
> >>specific byte-range of the indicated object, even though the 
> >>underlying protocol does.  Should URLFETCH provide a way to do 
> >>partial fetches?  How about BURL or CATENATE?
> >
> >There was discussion not too long ago that IMAPURL needed to be 
> >updated anyway. Adding byte-ranges to the URL would get them into 
> >URLFETCH, BURL, and CATENATE by reference automatically.
> 
> While this makes sense, I'm a bit concerned by the http precedent:
> HTTP-the-protocol support sub-ranges retrieval, why doesn't
> http-the-schema?  Is it because HTTP has difficulty with mutable
> resources, as seen in the rules around validators and sub-range
> requests?  If so, then adding byte-range syntax to the imap schema
> should be fine, at least when a UIDVALIDITY is also specified, as IMAP
> provides strong immutability guarantees in that case.
> 
> Are there any existing schemata that define byte-range (subobject?)
> access whose example the imap schema could follow
> 
> 
> Philip Guenther
>

---

From: [email-masked]
Date: Tue, 23 Nov 2004 19:55:44 -0600

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Mark Crispin
> Sent: Tuesday, November 23, 2004 5:39 PM
...
> On Tue, 23 Nov 2004 [email-masked] wrote:
> > The granularity of an arbitrary slice of bytes
> > of either a message or a section for authorization does not make
> > sense to me.
> 
> I can think of use cases; but I agree that these use cases aren't 
> particularly exciting given that there's always the existing 
> choice of 
> download-then-forward.
> 
> I'm not going to jump up and down for this functionality.  I'm just 
> pointing out that it has a use which is not duplicated by any other 
> proposal.  If we decide that this functionality is not 
> important (and that 
> is a question that I will "abstain" on), then there is no 
> need to modify 
> IMAP URLs because it can be done in the URLFETCH command.

I think signed byte ranges would be of dubious value. This is not
the same as saying that IMAP URLs would be of no importance.

Summary of my opinion is:
1) IMAP URLs should have byte ranges added.
2) Commands that take IMAP URLs as the identity of a byte stream 
should not have additional byte range arguments qualifying that same
byte stream.
3) URLAUTH can have a sensible syntax defined that allows a signed
URL without signing the byte range defined in that URL.

Mike