Subject: [UM] IETF 54 LEMONADE minutes

From: Glenn Parsons <[email-masked]>
Date: Wed, 31 Jul 2002 09:30:06 -0400

Folks,

Here are the minutes from the LEMONADE BOF at IETF 54.  Let us know if you
have any comments in the next few days as we need to send in the minutes to
the IETF proceedings.

Cheers,
Glenn.

Minutes of LEMONADE BOF
Thursday July 18, 2002, 3:30 pm

Co-chairs:      Glenn Parsons <[email-masked]>
                Eric Burger <[email-masked]>

Minutes:        Abbie Barbir <[email-masked]>

Introduction 
------------ 

.   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 [email-masked] with  "subscribe um" in body
    Archive is at http://flyingfox.snowshore.com/um_archive/maillist.html

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

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

Question/remarks 
-    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
applications 
-       What specific things that needs to be meet for internet mail

Questions/remarks 
-       is this mostly an IMAP document, needs to be reworked as a general
purpose 
document 
-       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. 

Question/remarks 
-       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 -
draft-shviedel-mediasize-00
-------------- 

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

Questions/remarks 
-       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 -
draft-vaudreuil-futuredelivery-00
-------------- 

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

Questions/Remarks 
-       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
-------------- 

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

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

Charter Review 
-------------- 

Questions/remarks 
-       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 requirements
-       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
behavior. 
-       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 
focused. 
-       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.