concluded.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
|