Subject: [lemonade] Raw Draft Meeting Minutes

From: "Eric Burger" <[email-masked]>
Date: Wed, 30 Jul 2003 21:33:16 -0400

Meeting notes of LEMONADE group meeting by Chanh Phung
	
Meeting in Room LM @ Vienna Center

Chairs : Glenn Pearson
	Eric Burger

Agenda bashing - 10 min 
No issue

LEMONADE Goals (ex Requirements) - 40 min 
  - draft-lemonade-goals-00.txt - Editor Kue Wong 
should we have an architecture as well? 

Charter was shown.
Q: should it be IMAP4 ?
A: Yes, it is explicitly written in the charter.
One of the notes from the chair is to extend email to wireless handset.

IMAP4 extensions for mobile devices - 30  
       - draft-lemonade-imap-submit-xx.txt - Editor Randall Gellens 
    - draft-shveidel-mediasize-02.txt 
   - draft-vaudreuil-futuredelivery-01.txt 
Slides:
-	Issue & architecture document.
-	Draft from 4 earlier drafts, started from IETF 56. Has sections on client-model, internet mail enhancement, detailed requirements for telephone interface and wireless handheld.
-	New material adds cellular perspective to text and multimedia messaging.
-	Push-notification delivery
-	E.164 delivery
-	Discussions about the enhancements to IMAP4
Issues:
-	Tighter spec of IMAP4 enhancements for limited capability clients
-	Tighter spec of requirements for notification format and mechanism
-	IMAP support for interworking with MMS
-	More detailed architectural description or separate architectural document

Q. Should it be only mobile handheld or expand to TUI ?
Randy. Did not see anything about user interface in the charter, only networking, memory, bandwidth, latency related constraints.
Glenn. The goal doc explains the environment, but do not get into what the TUI should be. It specifies the use cases and the problems to solve. More as a description of the requirement, not design doc.
Randy. Are we
Greg. There are things beyond network efficiency, but protocol related in order to support TUI features.
Glenn. Agree. Request review the goal document and comment on what should be added/deleted.
Randy. Are we committing to go to RFC with this goal document ? Good about a guiding document, but not useful as an informational RFC.
Glenn. Good point. Need to focus on use case. Decision to publish this document should be later.
Vote : not working on TUI.
Glenn. Request to study and comment on this document to identify work items.

Q. Request feedbacks on contents.
Glenn. Start a new thread on the mailing list for each content item.

IMAP push/pull (draft-ietf-lemonade-submit-00.txt)- Randy
Forward without download: Allow IMAP client to include previously-received message without downloading
Push mechanism:
1.	Annotated outbox/external agent: requires annotation support by the client.
2.	IMAP does submit intrinsically: add message submission to IMAP.
-	Require IMAP the capability to queue message
-	Generate DSN
-	Forward to smart
-	OK from IMAP does not mean message accepted
-	Client polls message to learn status or get DSN
-	Add complexity to IMAP for limited cases: non-SMTP submit (e.g. IM)
-	Admin complexity
3.	Proxy/submit server: few changes to IMAP
-	Does not return OK until get ack from submit -> longer submission
-	Submit server has to authenticate to IMAP server -> new authentication and authorization.
Comments:
-	#2. have a choice to deprecate message submission, or have two parallel message submission.
-	#2 vs. #3. different client 
-	#3. submit server and IMAP server can be co-located.
-	Suggest to add a design goal (elegance vs. efficiency)
-	All 3 options define a new submission protocol, not only #2 and #3. Good point.

Pull mechanism: Pawn ticket. Per user mailbox secret.
Comment.
-	Randy. There are some interesting usage for the pawn ticket model.
-	Dave. Great summary of the draft. Composition should be tightly with IMAP function and composition by reference is not a good idea. Double login is not a big deal. Ticket mechanism is a risk.
-	Glenn. Is trigger to submit assumed ? different mechanism would have different assumption.
-	Chris. Need two composition services: full composition, compose and append. Both are already adopted.
-	Chris. was a proponent of IMAP push model. Should not have multiple ways to submit for IM, etc. Now a proposal of IMAP pull model.
-	xxx. Need to focus on the split client-model decision.
-	Lisa. Same problem is resolved in IM, using URI instead of attach the whole thing. Please consider this model.
-	Eric. The requirement is the object is there whenever needed, regardless of pull/push/reference. A scenario to consider is when one client delete, the other client forward, and the reference should be managed accordingly.
-	Eric. Should the protocol protects the user from wrongful use ?
-	Dave. Let's take the ticket mechanism out of the scope of immediate resolution.
-	Randy. Assumption about trusted environment is probably not acceptable.
-	Dave. Let's figure out what is useful for our users ??? Ticket mechanism is a high risk item.
-	Pete. Ease of implementation should be the most important.
-	Pete. IMAP composition should be a separate issue. Push or pull would be determined later.
-	Vote. Support client compose and append.
-	xxx. Design the system in a modular way to take on authentication later.
-	Glenn. Have two questions to vote.
-	Eric. It is premature to vote now. Should wait until Pete's work 
-	Vote. Should have only one RFC for the chosen option.
-	Vote. Split between push and pull.
	
Draft-shveidel-mediasize-02
Q. Should it be a working group doc ?
Vote. Not a working group item.
Comments:
Ari. Willing to limit the scope to make it a working group doc. It is ready, but needs reviews.
Chris. Have substantial work load for the charter. Willing to give expert review but not working group item.

Draft-vaudreuil-futuredelivery-01
Q. Should it be a working group doc ?
Vote. It is a working group doc.
Comments.
This work item should be part of IMAP push/pull.
The document will continue as usual. The document will be absorbed to the push/pull document whenever necessary.

IMAP4 profile for mobile devices - 5 min 
   - volunteers will be solicited in Vienna 

Translation to and from other messaging systems - 10 min 
-	draft-gellens-lemonade-mms-mapping-00.txt. 
Vote: This is a working group doc.
Slides
Mapping between email and MMS.
MMS delivery and read report is text, not multipart.
MMS specific features: sender addr hiding, reply charging.
X-MMS-* headers
Comments.
Eric. How this work is shared with 3GPP and 3GPP2 ?
Randy. This should be published as RFC, then reference by 3GPP2.

Server-to-Server Notification Protocol - 5 min 
    - brief discussion of direction   

IMAP4 extensions for streaming VM playback - 10 min 
   - draft-lemonade-imap-channel-xx.txt - Editor Eric Burger 
Comments.
Pete. Lyndon is the new editor of this document.

Milestone bashing - 10 min 

Deliverables:
Discussed, updated and agreed.

Milestones:
Discussed, updated and agreed.

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