[lemonade] DRAFT Minutes

[Eric Burger <[e-mail]>]

Are posted at
<http://www3.ietf.org/proceedings/07jul/minutes/lemonade.txt>

Copied here for your convenience.  Note there are a few consensii.  Please
look at the minutes here and start a new thread on the lemonade list if you
do NOT agree.

Lemonade Minutes, Day 1

- OMA to clarify the architecture slide: the division of boxes and
   marking/coloration wasn't completely clear and/or correct
   (mail store vs mail store behaviour)
- OMA to confirm what is meant by Unicode support
   - if it is a reference to GB 18030, then need to make sure everyone
     understands the effects and complications.  For example,
     transformation between GB 18030 <==> Unicode is not necessarily
     a bijection
- Barry to suggest non-normative implementation note regarding binary
   content for CONVERT document
- Cyrus to suggest text for "no access" flag to handle NOTIFY ACL issue
- Alexey to register new message event types in NOTIFY
- Dave to comment on slide 7 of NOTIFY slides
- get next rev of NOTIFY draft
  - need more stuckees on doing review on the CONTEXT/NOTIFY integration
- Randy to suggest text regarding automatic fetching of BODY[*] via NOTIFY
- Dave to finish his document regarding IMAP URL extensions


(Respectfully submitted, Philip)

========================================

Lemonade, Session 2, July 24th, 2007
Chairs:  Eric Burger, Glenn Parsons

Agenda as originally posted

Randy Gellens  presented the message events draft and review open issues.
 In resolution of the first open issue (anchor 11) the group present came to
consensus
 that the existing text
would be retained.  For the second open issue (anchor 23):
Should the mailbox admin events be on the exceptions list? The group present
said 
that it would be added to the exceptions list because of lack of deployment.
Randy will update the draft and request a new last call.

Barry Leiba then reviewed the IMAP-sieve script and the discussion in
the SIEVE meeting.  A use case will be added to the Lemonade document.
Randy reviewed the differences between the single-client and multiple
clients cases for update of sieve scripts.  Randy Gellens has taken an
action to provide text on the multiple client mechanism in a hierarchy.  He
will
send it to the list for review. He notes that clients are "write only" as
far as a current 
client implementations are concerned, and his text will address.  Barry
discusses
Issue 2, allowing transient editor header actions, to apply for the
execution of the
script for redirect.  It was discussed, and the group present came to
consensus that the text would remain as is.  A later extension to handle
this could be created if a compelling
use case is present.  The group next took up the question of whether
Expunge should be an imap-sieve event?  The group present came to consensus
that the mailing list would be polled for additional interest, as there is
currently
only one interested developer.  If there is no additional interest, there
seems
to be no objection to it as an extension.  Barry then asked whether the
references
to sieve extensions be normative or informative? The group came to consensus
that they
should be normative, and he will update the text, except for the cases where
the referenced extension is disallowed.

The group then discussed profile bis, with Alexey presenting the issues.
There have been no updates since Prague.  SASL-IR will be added (it is
currently in the RFC editors
queue).  Sort has also been added.  Comparator is a dependency as is enable.
Zoltan asked whether IDLE is necessary if NOTIFY is present? Alexey notes it
was a
dependency in Profile.  Rough consensus to keep it in.

In discussing streaming, the group present came to consensus that it will
remain outside the profilebis document scope.  For quickstart, the group
present came to consensus that it will remain outside the profilebis
document scope.  The group discussed the placement
of notifications discussion; this did not come to consensus on placement in
the room.  A small design team, led by Randy Gellens, will make a proposal
to the list in three weeks.

CMCC then discussed interoperability testing for lemonade.  This would not
be an IETF meeting, though data on the interoperability would be sent to the
list and ADs.  An invitation to this, should one be planned, will also be
sent to the list.





Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.


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