Current Meeting Report

2.1.12 License to Enhance Messaging Oriented Network Access for Diverse Endpoints(lemonade) Bof

Current Meeting Report

Thursday July 18, 2002, 3:30 pm

Co-chairs: Glenn Parsons <>
Eric Burger <>

Minutes: Abbie Barbir <>


. Glenn described the origin of the acronym
. Agenda bashing
. LEMONADE came from VPIM WG
. Looked at client to server interaction
. Should the work be done in FAX and VPIM? Decided to create a BOF to address
these issues
. 10 drafts are already in
. 4 residual from the VPIM, these are closer to finish and may happen in VPIM
. To subscribe to the mailing list:
send message to with "subscribe um" in body

Archive is at

Lemonade Requirements - Eric Burger - draft-burger-um-reqts-00

. A lot of the service providers like to move internet standard way into 3GPP

- make sure that you check what the IETF already has
- Is this going to go in the direction like Midcom
- Are we changing protocols that require big machines or are taking them as is
- We do not have any protocols between the application and the link layer
- Other issues other than memory constraints that need to be addressed
- Will the charter require that this WG not touch any other protocol
- Look at six years ago, this protocol must be changed and then we realized that
we may not need to. SNAP is something new that needed to be happened
- From application layer prospective we do not care about the lower layer we
need to use the same e-mail client regardless of what, the ultimate goal is to
use the same application regardless of the link layer, the question of how to go
from here to there.
- That what is the WG wants to do just look at that now
- May be we need gateways for the next 20 years. If the WG finds that that might
be interesting by itself.
- We may also discover that there is no answerer at this time

Lemonade Extensions - Greg Vaudreuil - draft-vaudreuil-um-issues-00

- specify the specific issues that Lemonade needs to meet for specific
- What specific things that needs to be meet for internet mail

- is this mostly an IMAP document, needs to be reworked as a general purpose
- this needs to be merged with other doc and have one general purpose doc
- this should be treated as a token for doing things
- now there is an assumption that there is exist a profile protocol, this may
not be the case.
- Having more generic justification may be useful, another doc may address if
there is a current solution
- What is the main problem statement
- We need a way for clients to negotiate with servers for a richer experience,
current environment is not rich enough
- Need a scenario and proper relation to a problem statement, allow us to see
the changes that need to be done
- In SIP we had a marketing requirements and then we needed a mid level
requirements that discusses what need to be done, other document may do more
down in details but all need to be able to access the top requirement doc.
Basically one very high level doc.

Unified messaging support for diverse clients, An architecture for Internet Mail
Evolution - Kue Wong - draft-wong-umcli-00

- challenge, to enable a simple uniform access to diverse messaging by diverse
client types. This is more of an approach as opposed to an architecture.

- it seems in the wireless use case is there a way in IMAP to get the
capabilities of the device.
- IMAP is a pull protocol, may not fit in the current scope of a WG
- If you do Transcoding from HTML to text, how u will filet that and how these
capabilities will done, how about content adaptation, are you going to be deal
with it or not, these need to be addressed in the requirement document.
- In the case of two UAs is similar to cases where the initial connection is
made with one device and then continue on another one? Perhaps the requirements
doc need more work to reflect this.
- Can help in scoping these extra applications
- Need to move away from dependency on the main server
- SIP may be able to help but it is heavy weight solution
- It would really help if you frame this doc as a problem doc as opposed to an
architecture, what are the needs of these wireless devices that we need to
address in the WG

SMTP Service extension for message Media Size declaration - Ari Erev -

- more directed towards a voice mail scenario, and assumes that SMTP will be

- I do not understand why the size for context type
- The context is defined only as a hint, is context confused by location maybe,
you can be done using location, how the server can allocate quota based on what
the client say, the client can lie.
- Do you think that is useless all together,
- Yes the context is useless for allocating quota
- May be we should use a protected quota for a specific super client
- One difference between this and the size extension is that it is less specific
than this application
- Not all servers well implement this
- We not need that.
- Question to Lisa, how about a trusted agent, UA?
- We do not think of that as a UA
- All depends on trust issues, which UA trust whom, there is no way of
determining what the size means.
- Do we really need to support a specific size unit

SMTP Submission service for Future delivery - Greg White -

- extension to allow a user submit a message and then it gets delivered later

- use SMTP to submit the message but use IMAP to edit the message
- customers nee delivery windows, just deliver mail based on time of day
- this also applies to the general requirements for SMTP
- this and many other extensions may end up discovering SMTP submission
- there are a class of things that people wanted to do and that one of the
points of the submission protocols does not allow u to that without SMTP
- there is a FAX doc that propose additional semantics that may need to be
re-scoped to get some of the requirements here.

Status Counters use cases - Ari Erev - draft-neystaft-imap-counters-00

- how long before we discuss if this a WG or not?

- there is a proposed charter, need to discuss if we go from BOF to WG
- we'll do that next

Charter Review

- we need a WG, but the charter is thin on specifics
- need to get the first three drafts as problems statements before a WG would go

- SNAP is one the document that was mentioned, notifications is hard, WEBDAV
could use that
- SNAP is very specific
- I support the suggestion to rework the drafts and get better charter
- There is more work that need to be done before this becomes a WG
- Do we need an instant for each protocol, or de we need a framework and after
that in place address each protocol.
- Regarding SIP notifications and it seems that SNAP solves a different problem.
This charter is not too bad, I say go for it.
- SNAP had poor sensibility primitives, poor job in defining in defining
counters and other stuff without creating problems. No objection to this working
group up to point step 3. Change item three in the charter to define
- We hope that SNAP gets finished before that this get chartered.
- My company does a document share store, many customers are frustrated with
e-mail servers with many copies of the same doc. How to store the document
somewhere else and say that to the client where it is. May need to add that to
step 2. is this in the scope
- The way to do that is a variation on other schemes for storing doc in a
different place. There are protocols that do that. It is more of a user
- User can only attach by attaching to e-mail. The e-mail client has no notion
of putting things.
- We do not want to solve it here.
- The charter is coherent but it really needs a better outline.
- We need to get out of device independence work, etc.., need to look very
- Hum time -- Is this subject matter of interest to IETF? (good hum)
- Patrik says that the charter need more clarification on issues like low bit
rate and everyone agreeing what it means, where it is, is this precise enough,
and why the conclusion is needed. Should continue such discussions, may should
have a little more of this matter. However this looks like a good charter,
discuss more on the mailing list and see if people are comfortable. Suggest we
go ahead with the chartering process, with one of the early milestones being to
revisit the charter.


IMAP Extension: Status-Counters
SMTP Service Extension for message Media Size declaration
SMTP Submission Service Extension for Future Delivery
Overview Mobile Messaging
Unified Messaging Support for Diverse Clients - An Architecture for Internet Mail Evolution
Extensions for Lemonade
Lemonade Requirements