Subject: [lemonade] IMAP URLS

From: Peter Coates <[email-masked]>
Date: Wed, 05 Sep 2007 11:55:13 -0700

RFC 2192 (IMAP URLs) says in section 7:

     The [isection] field is optional.  If not present, the URL refers

     to the entire Internet message as returned by the IMAP command "UID

     FETCH <uid> BODY.PEEK[]".  If present, the URL refers to the object

     returned by a "UID FETCH <uid> BODY.PEEK[<section>]" command.  The

     type of the object may be determined with a "UID FETCH <uid>

     BODYSTRUCTURE" command and locating the appropriate part in the

     resulting BODYSTRUCTURE.  Note that unsafe characters in [isection]

     MUST be encoded as described in [BASIC-URL].

So for instance, I could have a relative IMAP URL 

"/inbox/;uid=59917/;section=header.fields (date from)".

RFC3501 says in section 6.4.5

         The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part

         specifiers refer to the [RFC-2822] header of the message or of

         an encapsulated [MIME-IMT] MESSAGE/RFC822 message.

         HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of

         field-name (as defined in [RFC-2822]) names, and return a

         subset of the header.  The subset returned by HEADER.FIELDS

         contains only those header fields with a field-name that

         matches one of the names in the list; similarly, the subset

         returned by HEADER.FIELDS.NOT contains only the header fields

         with a non-matching field-name.  The field-matching is

         case-insensitive but otherwise exact.  Subsetting does not

         exclude the [RFC-2822] delimiting blank line between the header

         and the body; the blank line is included in all header fetches,

         except in the case of a message which has no body and no blank

         line.

so presumably the result of the imap URL would include the extra CR/LF 

at the end except in the case mentioned.  This is IMHO not as useful in 

CATENATE as it could be

I can see some virtue in being able to say in an append

1 append drafts catenate (url "/inbox/;uid=59917/;section=header.fields.not
(date from)" text {89+}

Date: Tue, 28 Aug 2007 21:31:25 -0700 (PDT)

From: [email-masked]

12345678

)

With the interpretation of the RFC that I think is the strict reading this
would not work as I would get an extra CR/LF back after the requested
headers.  Do other people read the RFC the same way, and if so what have
they implemented?

In the interest of full disclosure I should say that I do not return this
CR/LF.

Peter

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

---

From: Mark Crispin <[email-masked]>
Date: Wed, 5 Sep 2007 13:05:41 -0700 (PDT)

> In the interest of full disclosure I should say that I do not return this

If your server implementation violates the specification in this way then 
it is non-compliant and broken.

Please fix this problem as soon as possible and let me know when it is 
fixed (and preferably which version fixes it).  Thank you.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 05 Sep 2007 21:23:26 +0100

Mark Crispin wrote:

> If your server implementation violates the specification in this way 
> then it is non-compliant and broken.

*Which* specification? I think Peter was talking about Catenate and not 
RFC 3501 FETCH.

---

From: Mark Crispin <[email-masked]>
Date: Wed, 5 Sep 2007 13:34:29 -0700 (PDT)

On Wed, 5 Sep 2007, Alexey Melnikov wrote:
> *Which* specification? I think Peter was talking about Catenate and not RFC 
> 3501 FETCH.

If that was the case, then CATENATE would have to disregard trailing CRLFs 
at the end of a header piece being catenated, but somehow have to figure 
out when it's in a header and when it isn't.  Also, Peter says "return 
this CR/LF", not "disregard this CR/LF."

Or, perhaps, he's talking about URLFETCH (assuming that the CATENATE does 
a URLFETCH instead of resolving the URL internally...but I thought we 
agreed not to stipulate that in this version?).  If that's the case, then 
there's nothing in URLFETCH that says to truncate trailing CRLFs from 
message header parts.

The only way that I can interpret Peter's message that makes sense (at 
least to me) is if he's talking about FETCH.  And in that case, the IMAP 
specification is clear and unambiguous.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Peter Coates <[email-masked]>
Date: Wed, 05 Sep 2007 13:37:56 -0700

The specification for fetch is unambiguous and the CRLF has to be present
and is present in all implementations I'm aware of.

I am discussing IMAP URLS.

I am suggesting that the CRLF at the end of an IMAP URL that requests
header, or one that requests some headers NOT return the CRLF.  That would
affect URLFETCH and CATENATE.

Peter

-----Original Message-----
From: Mark Crispin [mailto:[email-masked]] 
Sent: September 5, 2007 13:34
To: Alexey Melnikov
Cc: Peter Coates; [email-masked]
Subject: Re: [lemonade] IMAP URLS

> *Which* specification? I think Peter was talking about Catenate and not
RFC 

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Wed, 5 Sep 2007 13:45:50 -0700 (PDT)

> and is present in all implementations I'm aware of.

Excellent, thank you.

> affect URLFETCH and CATENATE.

It does more than that.

Either URLFETCH and CATENATE have to have explicit language that states 
"in the event of a fetch of header data, the trailing CRLF is omitted", or 
every implementation of IMAP URL has to be changed to do this.

It also begs the question of what to do if you CATENATE BODY[HEADER] and 
BODY[TEXT].  Does this mean that you have to add a CRLF literal between 
the two?

Note that you could accomplish what you want in your example by 
CATENATEing literal text with the added headers (but no trailing CRLF) 
first, then the rump header from partial fetching.  That would have the 
effect of putting the added headers before any Received: lines (which is 
probably why you didn't do it that way) but IMHO it is dishonest to change 
the From: and preserve Received: lines so I'm not particularly worried 
about that problem.

Your overall point is a good one, and it's something that should have been 
raised long ago when partial header fetching was discussed in the IMAP 
base specification.  But I'm afraid that it's over a decade too late to 
close that barn door.

-- Mark --

http://panda.com/mrc

---

From: Dave Cridland <[email-masked]>
Date: Wed, 05 Sep 2007 22:20:07 +0100

On Wed Sep  5 21:45:50 2007, Mark Crispin wrote:
> CATENATEing literal text with the added headers (but no trailing  
> CRLF) first, then the rump header from partial fetching.  That  
> would have the effect of putting the added headers before any  
> Received: lines (which is probably why you didn't do it that way)  
> but IMHO it is dishonest to change the From: and preserve Received:  
> lines so I'm not particularly worried about that problem.

Indeed, it's not too difficult to do - the typical use-case for this  
is editing the subject line on a draft, rather than trying to mangle  
a message with Received headers already present.

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