Subject: RE: [lemonade] Profile WG last call

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Tue, 25 Oct 2005 14:52:14 -0500

I have the following comments after reviewing the latest version of the profile, 05.
 
Last work in 2nd to last paragraph of Page 4  "server" => "Client or MUA".  Server already has the fragments.
 
Last paragraph of Page 4 introduces two new concepts without describing what they are '"forward without download" strategy' and 'variant'.  Text saying 
 
    "There are two use variants based on where the message assembly takes place .  The first uses
     a succession of BURL and BDAT commands to submit and assemble through concatenation, 
     message data from the client and external data fetched from the provided URL. The second uses 
     the Catenate command to upload a template to the message store and cause the message assembly
     on the IMAP server."  
 
At least, that is what I think the authors were thinking but not stating.    Along those lines, do we need an example of the first variant?  The only text describing this variant is in section 2.5 explaining why chunking needs to be supported.

Section 2.6, second paragraph.  If I understand this, the client can't revoke the validity of the pawn-ticket.  That revocation has to be done on and by the IMAP server itself.  Is there an way for the client to request that a URLAUTH be invalidated?  

Section 2.7.
 
A sentence or two about how to actually use catenate to solve the FCC problem would help.  Is the solution to move the template into the "sent items" mailbox prior to requesting a URLAUTH?   Do we need to discuss "sent items" conventions here?  
 
Section 3.1
 
"clients should pipeline" may be more completely worded "clients should pipeline SMTP commands when possible".  
 
Normative references section is missing RFC 2034 required in 3.4
 
Greg V.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Glenn Parsons
Sent: Tuesday, October 25, 2005 11:22 AM
To: [email-masked]
Subject: [lemonade] Profile WG last call

Folks, 

This message announces the commencement of the WG last call on the LEMONADE profile: 
 <http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-05.txt> http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-05.txt 

Please review this document paying special attention to: 
 - the list of MUST implement features 
   (note the editors suggest adding IDLE and $forward to the 
    baseline we agreed in London) 
 - the noted open issues 

Last call will end 9am on Nov 7th. 

Cheers, 
Glenn. 

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

---

From: Mark Crispin <[email-masked]>
Date: Tue, 25 Oct 2005 13:28:58 -0700 (Pacific Daylight Time)

On Tue, 25 Oct 2005, Vaudreuil, Greg M (Greg) wrote:
> Section 2.6, second paragraph.  If I understand this, the client can't 
> revoke the validity of the pawn-ticket.  That revocation has to be done 
> on and by the IMAP server itself.  Is there an way for the client to 
> request that a URLAUTH be invalidated?

A client can revoke all URLAUTHs issued for that user by using RESETKEY. 
Individual revocation is not possible.

-- Mark --

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 26 Oct 2005 15:39:22 +0100

Hi Greg,
Thanks for the comments.
I've replying to the obvious comments first.

> MUA".  Server already has the fragments.

Fixed, thanks.  

> Section 3.1
>  
> "clients should pipeline" may be more completely worded "clients 
> should pipeline SMTP commands when possible".

Changed. 

> Normative references section is missing RFC 2034 required in 3.4

I see such reference in the posted document?

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 28 Oct 2005 15:53:04 +0100

Vaudreuil, Greg M (Greg) wrote:

> Last paragraph of Page 4 introduces two new concepts without 
> describing what they are '"forward without download" strategy' and 
> 'variant'.  Text saying
>  
> At least, that is what I think the authors were thinking but not 
> stating.    Along those lines, do we need an example of the first 
> variant?  The only text describing this variant is in section 2.5 
> explaining why chunking needs to be supported.

The original text was taken from Mark's document about different pull 
variants. So it has to be rewritten.
One way of rewriting would be to add something like the text you've 
suggested and add another example.

Let's discuss this during the upcoming Lemonade WG meeting.

> Section 2.7.
>  
> A sentence or two about how to actually use catenate to solve the FCC 
> problem would help.

Sure.

> Is the solution to move the template into the "sent items" mailbox 
> prior to requesting a URLAUTH?

The solution is to catenate the final message to the "sent items" mailbox.

>    Do we need to discuss "sent items" conventions here?  

We can get away without such discussion by saying that the sent items 
mailbox is "a mailbox where you want to have your final message".

However, one can have a per-user annotation or a NAMESPACE command 
extension to specify the default "sent items" mailbox, so that users can 
have consistent behavior across multiple mail clients. Is it something 
that people want to pursue for Phase 1 or in general?

Just my opinion.

Alexey

---

From: Anil SRIVASTAVA <[email-masked]>
Date: Fri, 28 Oct 2005 14:22:58 -0700 (Pacific Daylight Time)

On 2005-10-28/15:53 [+0100], [email-masked] [Alexey Melnikov] wrote:

> extension to specify the default "sent items" mailbox, so that users 
> can have consistent behavior across multiple mail clients. Is it 
> something that people want to pursue for Phase 1 or in general?
> 

I would like to see us pursue this in general (and maybe phase 2 of the 
profile).  Having 'sent items' and 'draft' mailboxes specified as a 
NAMESPACE command extension make sense.

> Alexey

_______________
Anil SRIVASTAVA
[email-masked]

---

From: Mark Crispin <[email-masked]>
Date: Fri, 28 Oct 2005 14:46:28 -0700 (Pacific Daylight Time)

> NAMESPACE command extension make sense.

Swamp.  Slippery slope.  Quagmire.

I do not think that it would be wise to step into this.  There are many 
stakeholders to the concepts of "sent items" and "draft" whose interests 
would be threatened by an attempt to bless one particular scheme of these 
concepts.  If the chosen scheme is incompatible with their installed base, 
it is safe to assume that they will protest.

Unfortunately, it is unlikely that any one scheme can be chosen which will 
be compatible with what all of these stakeholders are doing.

Something done with annotations, or preferably ACAP, would probably not 
trigger such objections.  In that case, however, I think that there should 
be a specific LEMONADE (not IMAP) definition of "sent items" and "drafts". 
This removes the threat, while still creating an incentive.

To be specific: the threat is an ex post facto declaration that you are 
not IMAP-compliant, whereas the incentive is to become LEMONADE-compliant.

It doesn't matter that it would be an extension to NAMESPACE; it would 
still have the effect of creating be "an IMAP definition" which renders 
existing clients non-compatible.  By being in NAMESPACE, it brings the 
IMAP server into the issue.

Hence the alternative of a LEMONADE definition, which is mandatory for 
LEMONADE clients and which other clients *may* adopt.  Ideally, the IMAP 
server is not brought in to the equation.

-- Mark --