From owner-um@snowshore.com Tue Jul 2 06:30:59 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id g62AUxf29956 for um-outgoing; Tue, 2 Jul 2002 06:30:59 -0400 (EDT) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from mail.notes.ricoh.co.jp (mail.notes.ricoh.co.jp [202.211.49.10]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g62AUrl29934 for ; Tue, 2 Jul 2002 06:30:54 -0400 (EDT) Received: from azteca.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.74]) by mail.notes.ricoh.co.jp (8.11.6/3.7W) id g62AUQF27905; Tue, 2 Jul 2002 19:30:26 +0900 Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by azteca.isd.ricoh.co.jp (Mirapoint) with ESMTP id ACZ49112; Tue, 2 Jul 2002 19:30:25 +0900 (JST) Received: from localhost (tulip.toda.ricoh.co.jp [133.139.60.74]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id TAA00373; Tue, 2 Jul 2002 19:26:08 +0900 (JST) To: gparsons@nortelnetworks.com Cc: vpim@lists.neystadt.org, ietf-fax@imc.org, um@snowshore.com Subject: [UM] Re: Draft Agenda for VPIM From: Hiroshi Tamura In-Reply-To: <20020627075755F.tamura@toda.ricoh.co.jp> References: <20020627075755F.tamura@toda.ricoh.co.jp> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020702181542E.tamura@toda.ricoh.co.jp> Date: Tue, 02 Jul 2002 18:15:42 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 34 Sender: owner-um@snowshore.com Precedence: bulk Glenn, > > TUESDAY, July 16, 2002 > > 0900-1130 Morning Sessions > > APP fax&vpim Internet Fax WG & Voice Profile for Internet Mail WG > > > > Anyway, on the meeting agenda, I would propose FAX goes first and that VPIM > > progresses in a similar order of events as we have done previously: > > Your proposal for FAX WG going first is ok for me. I live in Yokohama! > But, some FAX WG members do not stay at hotels and go there > directly from their home. > > Dear Japanese FAX WG members: > If you take the first train in the morning and cannot go there, > please let us know very soon. I received the comments from them personally. They told me they are OK. Let's start FAX WG first. > Regarding FAX WG agenda, I will let you know the next Tuesday, maybe. > The issues are mainly confirmation of status of I-Ds that FAX WG finished, > TIFF-FX, ESMTP CONNEG, Claudio's I-D, FAX in ENUM and ITU. > Please wait. I mail in another thread sooner or later. Regards, -- Hiroshi Tamura, Co-chair of IETF-FAX WG E-mail: tamura@toda.ricoh.co.jp - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Tue Jul 2 06:31:02 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id g62AUvr29950 for um-outgoing; Tue, 2 Jul 2002 06:30:57 -0400 (EDT) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from mail.notes.ricoh.co.jp (mail.notes.ricoh.co.jp [202.211.49.10]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g62AUrl29935 for ; Tue, 2 Jul 2002 06:30:54 -0400 (EDT) Received: from azteca.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.74]) by mail.notes.ricoh.co.jp (8.11.6/3.7W) id g62AUQF27909; Tue, 2 Jul 2002 19:30:26 +0900 Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by azteca.isd.ricoh.co.jp (Mirapoint) with ESMTP id ACZ49113; Tue, 2 Jul 2002 19:30:25 +0900 (JST) Received: from localhost (tulip.toda.ricoh.co.jp [133.139.60.74]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id TAA00376; Tue, 2 Jul 2002 19:26:09 +0900 (JST) To: ietf-fax@imc.org cc: ned.freed@mrochek.com, claudio.allocchio@garr.it, vpim@lists.neystadt.org, um@snowshore.com Subject: [UM] IETF-FAX WG Draft agenda at Yokohama From: Hiroshi Tamura X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020702192404Q.tamura@toda.ricoh.co.jp> Date: Tue, 02 Jul 2002 19:24:04 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 67 Sender: owner-um@snowshore.com Precedence: bulk Folks, Here is the draft agenda for FAX WG at Yokohama. If you have comments, please say by Jul 5. [[[]]] is comment. -- Hiroshi Tamura, Co-chair of IETF-FAX WG tamura@toda.ricoh.co.jp --------------------------------------------------------------------- 1 Agenda Bashing (2 min) 2 The I-Ds which IESG approved and are in RFC editor's queue (1 min) - draft-ietf-fax-implementers-guide-08.txt Reference issue of tiff-fx-reg I-D - draft-ietf-fax-content-negotiation-05.txt - draft-ietf-fax-tiff-regbis-05.txt Urgent Action is necessary for TIFF-FX for Draft Standard. 3 The I-Ds for which IETF Last Call was finished (2 min) - draft-ietf-fax-tiff-fx-reg-01.txt Urgent Action is necessary for TIFF-FX for Draft Standard. - draft-ietf-fax-gateway-protocol-08.txt - draft-ietf-fax-gateway-options-05.txt - draft-ietf-fax-service-v2-05.txt Reference issue of DSN (RFC1894) and TIFF-FX (draft-ietf-fax-tiff-fx-11.txt) 4 The I-D which IESG is reviewing (Before IETF Last Call) (1 min) - draft-ietf-fax-timely-delivery-05.txt Reference issue of draft-vaudreuil-1983ext-01.txt 5 TIFF-FX implementation report (10 min) The original report and the additional (new) report to be submitted. [[[The new report is not submitted here. I introduce the on-going status.]]] 6 SMTP Service Extension for Content Negotiation (25 min) - draft-ietf-fax-esmtp-conneg-02.txt [[[There seems to be lots of discussions.]]] 7 FFPIM (5 min) - draft-ietf-fax-ffpim-01.txt 8 Addressing (5 min) - draft-allocchio-gstn-03.txt 9 FAX in ENUM (5 min) [[[Toyoda-san is preparing for something.]]] [[[Can we add in our milestone?]]] 10 ITU issue (2 min) - Plan for October ITU SG16 meeting Implementers-Guide TIFF-FX issue 11 Confirmation of milestone (2 min) - TIFF-FX for Draft Standard Urgent action need that tiff-fx reg I-D should be Proposed Standard Implementation report - FFPIM - ESMTP CONNEG - Addressing - FAX in ENUM ??? - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Mon Jul 8 00:33:19 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id g684XGk28412 for um-outgoing; Mon, 8 Jul 2002 00:33:16 -0400 (EDT) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from mail.notes.ricoh.co.jp (mail.notes.ricoh.co.jp [202.211.49.10]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g684XDl28408 for ; Mon, 8 Jul 2002 00:33:14 -0400 (EDT) Received: from azteca.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.74]) by mail.notes.ricoh.co.jp (8.11.6/3.7W) id g684WYF23814; Mon, 8 Jul 2002 13:32:34 +0900 Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by azteca.isd.ricoh.co.jp (Mirapoint) with ESMTP id ADA17544; Mon, 8 Jul 2002 13:32:33 +0900 (JST) Received: from localhost (tulip.toda.ricoh.co.jp [133.139.60.74]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id NAA02014; Mon, 8 Jul 2002 13:28:13 +0900 (JST) To: ietf-fax@imc.org, gparsons@nortelnetworks.com Cc: ned.freed@mrochek.com, claudio.allocchio@garr.it, vpim@lists.neystadt.org, um@snowshore.com Subject: [UM] Re: IETF-FAX WG Draft agenda at Yokohama From: Hiroshi Tamura In-Reply-To: <20020702192404Q.tamura@toda.ricoh.co.jp> References: <20020702192404Q.tamura@toda.ricoh.co.jp> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020708133241V.tamura@toda.ricoh.co.jp> Date: Mon, 08 Jul 2002 13:32:41 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 70 Sender: owner-um@snowshore.com Precedence: bulk Folks, Regarding draft-ietf-fax-tiff-fx-reg-01.txt, IESG has just approved it at the end of Last Week. Thus, I change it to section 2. Also, I increased the estimated time for ESMPT CONNEG and added the url for new version. Glenn, Shall I combine fax-wg agenda and vpim-wg agenda and send it to agenda@ietf.org? Regards, -- Hiroshi Tamura, Ricoh Company, LTD. tamura@toda.ricoh.co.jp --------------------------------------------------------------------- 1 Agenda Bashing (2 min) 2 The I-Ds which IESG approved and are in RFC editor's queue (1 min) - draft-ietf-fax-implementers-guide-08.txt - draft-ietf-fax-content-negotiation-05.txt - draft-ietf-fax-tiff-regbis-05.txt - draft-ietf-fax-tiff-fx-reg-01.txt Urgent Action, i.e. Assignment of RFC Number, is necessary for TIFF-FX for Draft Standard. 3 The I-Ds for which IETF Last Call was finished (2 min) - draft-ietf-fax-gateway-protocol-08.txt - draft-ietf-fax-gateway-options-05.txt - draft-ietf-fax-service-v2-05.txt Reference issue of DSN (RFC1894) and TIFF-FX (draft-ietf-fax-tiff-fx-11.txt) 4 The I-D which IESG is reviewing (Before IETF Last Call) (1 min) - draft-ietf-fax-timely-delivery-05.txt Reference issue of draft-vaudreuil-1983ext-01.txt 5 TIFF-FX implementation report (5 min) The original report and the additional (new) report to be submitted. 6 SMTP Service Extension for Content Negotiation (30 min) - draft-ietf-fax-esmtp-conneg-02.txt - http://www.brandenburg.com/specifications/draft-ietf-fax-esmtp-conneg-03.txt 7 FFPIM (5 min) - draft-ietf-fax-ffpim-01.txt 8 Addressing (5 min) - draft-allocchio-gstn-03.txt 9 FAX in ENUM (5 min) 10 ITU issue (2 min) - Plan for October ITU SG16 meeting Implementers-Guide TIFF-FX issue 11 Confirmation of milestone (2 min) - TIFF-FX for Draft Standard Urgent action need that tiff-fx reg I-D should be Proposed Standard Implementation report - FFPIM - ESMTP CONNEG - Addressing - FAX in ENUM ??? - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Wed Jul 17 04:11:33 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id g6H8BQ629600 for um-outgoing; Wed, 17 Jul 2002 04:11:26 -0400 (EDT) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g6H8BNM29592 for ; Wed, 17 Jul 2002 04:11:23 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6H8BBU08971 for ; Wed, 17 Jul 2002 04:11:11 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Jul 2002 04:11:11 -0400 Message-ID: From: "Glenn Parsons" To: um@snowshore.com Cc: "Kue Wong" Subject: [UM] FW: I-D ACTION:draft-wong-umcli-00.txt Date: Wed, 17 Jul 2002 04:11:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22D69.81735812" Sender: owner-um@snowshore.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22D69.81735812 Content-Type: text/plain; charset="iso-8859-1" Folks, In case you have not seen this... Cheers, Glenn. * To: IETF-Announce: ; * Subject: I-D ACTION:draft-wong-umcli-00.txt * From: Internet-Drafts@ietf.org * Date: Wed, 26 Jun 2002 06:43:41 -0400 * CC: um@snowshore.com * Reply-to: Internet-Drafts@ietf.org * Sender: nsyracus@cnri.reston.va.us ------------------------------------------------------------------------ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Unified Messaging Support for Diverse Clients Author(s) : G. Parsons, J. Wong Filename : draft-wong-umcli-00.txt Pages : 9 Date : 25-Jun-02 This document describes an architecture for unified multimedia messaging -- capable of supporting clients of varying capabilities but based on extending existing IETF Internet Mail standards and infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wong-umcli-00.txt ------_=_NextPart_001_01C22D69.81735812 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: I-D ACTION:draft-wong-umcli-00.txt

Folks,

In case you have not = seen this...

Cheers,
Glenn.

=0D*      To: = IETF-Announce: ;=0D*  Subject: I-D = ACTION:draft-wong-umcli-00.txt=0D*   From: = Internet-Drafts@ietf.org=0D*        = Date: Wed, 26 Jun 2002 06:43:41 -0400=0D* CC: = um@snowshore.com=0D*  Reply-to: = Internet-Drafts@ietf.org=0D*    Sender: = nsyracus@cnri.reston.va.us=0D=0D----------------------------------------= --------------------------------=0D=0D=0DA New Internet-Draft is = available from the on-line Internet-Drafts = directories.=0D=0D=0D       = Title           : Unified = Messaging Support for Diverse = Clients=0D        = Author(s)       : G. Parsons, J. = Wong=0D  Filename        : = draft-wong-umcli-00.txt=0D      = Pages           : = 9=0D    Date    =         : = 25-Jun-02=0D    =0DThis document describes an = architecture for unified multimedia =0Dmessaging -- capable of = supporting clients of varying capabilities  =0Dbut based on = extending existing IETF Internet Mail standards and = =0Dinfrastructure.=0D=0DA URL for this Internet-Draft is:=0Dhttp://www.ietf.org/internet-drafts/draft-wong-umcli-0= 0.txt

------_=_NextPart_001_01C22D69.81735812-- - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html From owner-um@snowshore.com Wed Jul 31 09:30:40 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id g6VDUNo07024 for um-outgoing; Wed, 31 Jul 2002 09:30:23 -0400 (EDT) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g6VDULM07020 for ; Wed, 31 Jul 2002 09:30:21 -0400 (EDT) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6VDUDl19403 for ; Wed, 31 Jul 2002 09:30:13 -0400 (EDT) Received: from zcard04k.ca.nortel.com ([47.129.242.84]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PYGNA2QQ; Wed, 31 Jul 2002 09:30:13 -0400 Received: from [47.129.49.147] (acart41a.ca.nortel.com [47.129.49.147]) by zcard04k.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PY12N2BS; Wed, 31 Jul 2002 09:30:12 -0400 User-Agent: Microsoft-Entourage/9.0.2.4011 Date: Wed, 31 Jul 2002 09:30:06 -0400 Subject: [UM] IETF 54 LEMONADE minutes X-Sybari-Space: 00000000 00000000 00000000 From: Glenn Parsons To: Message-ID: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3110952606_743916" Sender: owner-um@snowshore.com Precedence: bulk > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3110952606_743916 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 Eric Burger Minutes: Abbie Barbir 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 majordomo@snowshore.com 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. --B_3110952606_743916 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable IETF 54 LEMONADE minutes 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 minute= s to the IETF proceedings.

Cheers,
Glenn.





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

Co-chairs:      Glenn Parsons <gparsons@norteln= etworks.com>
            &nb= sp;   Eric Burger <eburger@snowshore.com>

Minutes:        Abbie Barbir <abbieb@= nortelnetworks.com>


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 cre= ate 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 majordomo@snowshore.com with  = "subscribe um" in body
    Archive is at http://flyingfox.snowshore.com/um_arc= hive/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 an= d the link layer
-    Other issues other than memory constraints that need to= be addressed
-    Will the charter require that this WG not touch any oth= er protocol
-    Look at six years ago, this protocol must be changed an= d then we
realized that we may not need to. SNAP is something new that needed to be h= appened
-    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 o= f
how to go from here to there.
-    That what is the WG wants to do just look at that now <= BR> -    May be we need gateways for the next 20 years. If the W= G 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 Lemo= nade 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, need= s to be reworked as a general purpose
document
-       this needs to be merged with other do= c 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 negotiat= e with servers for a richer
experience, current environment is not rich enough
-       Need a scenario and proper relation t= o a problem statement, allow us to
see the changes that need to be done
-       In SIP we had a marketing requirement= s and then we needed a mid level
requirements that discusses what need to be done, other document may do mor= e
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 te= xt, how u will filet that and how
these capabilities will done, how about content adaptation, are you going t= o
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 appli= cations
-       Need to move away from dependency on = the main server
-       SIP may be able to help but it is hea= vy weight solution
-       It would really help if you frame thi= s 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 sc= enario, 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 ba= sed
on what the client say, the client can lie.
-       Do you think that is useless all toge= ther,
-       Yes the context is useless for alloca= ting quota
-       May be we should use a protected quot= a for a specific super client
-       One difference between this and the s= ize extension is that it is less
specific than this application
-       Not all servers well implement this <= BR> -       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 specif= ic size unit

SMTP Submission service for Future delivery - Greg White -
draft-vaudreuil-futuredelivery-00
--------------

-       extension to allow a user submit a me= ssage 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 requ= irements for SMTP
-       this and many other extensions may en= d up discovering SMTP submission
-       there are a class of things that peop= le 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 addit= ional 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 men= tioned, notifications is hard, WEBDAV
could use that
-       SNAP is very specific
-       I support the suggestion to rework th= e drafts and get better charter
-       There is more work that need to be do= ne before this becomes a WG
-       Do we need an instant for each protoc= ol, or de we need a framework and
after that in place address each protocol.
-       Regarding SIP notifications and it se= ems 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 befor= e that this get chartered.
-       My company does a document share stor= e, 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 independ= ence 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 mor= e 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 on= e of
the early milestones being to revisit the charter.

--B_3110952606_743916-- - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/um_archive/maillist.html