Subject: [lemonade] Profile Bis updated

From: Dave Cridland <[email-masked]>
Date: Tue, 03 Apr 2007 12:05:09 +0100

I've just submitted a fairly major update to the Profile document.

This update is quite intensive, and in particular, I've:

- Changed the references, so we now use named symbolic references. 
Hopefully this makes it easier to read the document. I've chosen to 
prepend the protocol name for the extension, which has the neat 
effect that all the SMTP extensions are listed together in the 
references.

- I've cleaned up the references, and ended up writing some support 
tools to help me minimize the number of Normative references.

- I've reorganized the document quite heavily. We now have the 
summary tables coming first, and the detailed normative sections 
next, and finally the informative sections.

- I've done some quick editing work too, to try and make the detailed 
normative sections read a little more fluidly, and try to get some 
consistency in our naming. In particular, the document now talks 
about "Lemonade Message Stores" and "Lemonade Submission Servers", 
the intention being that, for example, Cyrus IMAP can call itself a 
"Lemonade Message Store" (whereas it's not a Lemonade Mail Server, 
which has to provide both components).

This all means that looking at a diff is not going to help reviewers, 
and people are advised to simply read through the entire document 
again.

Things I've not done yet:

1) I have "Allow Partial URLs in CATENATE and URLAUTH" - are we going 
to require a capability tag to indicate this?

2) ENABLE - I've got ENABLE listed as something we'll need to be 
requiring, because it's needed for something else - but I cannot see 
what that something else is.

3) Section 8, the OMA MEM detail, is bothering me. In some private 
discussions, the opinion seemed to be to drop it entirely - I'm happy 
to keep it, but I'd rather trim it to it merely provides sufficient 
background that an OMA MEM member could use it to "bootstrap" 
themselves into understanding the Lemonade architecture. I'm not 
clear on what's required, so please advise, OMA-people.

4) I've probably not addressed all comments - if you find I have not, 
please send them to the list again.

I'd greatly appreciate some detailed reviews at this point, I'm 
intending to produce another revision as soon as I have a couple of 
reviews back.

Until it appears in the repository, you can find it at:

http://dave.cridland.net/draft-ietf-lemonade-profile-bis-05.txt

(For those working on other drafts in xml2rfc format, I now have a 
set of tools written in XSLT for preprocessing, reference checking, 
etc, if anyone is interested.)

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

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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 06 Apr 2007 12:43:56 +0100

> to require a capability tag to indicate this?

Yes, we should, as the client would otherwise have to way of knowing (it 
will have to try and see if partial URLs work).
Should we just do this in the Lemonade Profile Bis itself?

> what that something else is.

If I remember correctly, ENABLE was born around EXPUNGED/QRESYNC WGLC. 
In particular there was a suggestion to use ENABLE with CONDSTORE and 
QRESYNC. Is this something that people still would like to be able to do 
in Lemonade Profile Bis?