Some wrong characters in the submitted SMTP MediaSize = extension

From owner-um@snowshore.com Wed Jun 5 08:34:33 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id g55CYVL06557 for um-outgoing; Wed, 5 Jun 2002 08:34:31 -0400 (EDT) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from il-tlv-smtpout2.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g55CYRB06550 for ; Wed, 5 Jun 2002 08:34:27 -0400 (EDT) Received: from il-tlv-mbdg1.icomverse.com (il-tlv-mbdg1.comverse.com [10.116.200.32]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id g55CIWG27549; Wed, 5 Jun 2002 15:18:33 +0300 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id ; Wed, 5 Jun 2002 15:34:16 +0300 Message-ID: <7D4344E32B34D511A6500002A560C60202FC119B@il-tlv-mail4.comverse.com> From: "Erev, Ari" To: ietf-smtp@imc.org, vpim@lists.neystadt.org, um@snowshore.com Subject: [UM] Some wrong characters in the submitted SMTP MediaSize extension Date: Wed, 5 Jun 2002 15:34:16 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C20C8D.4E2A0476" 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_000_01C20C8D.4E2A0476 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20C8D.4E2A0476" ------_=_NextPart_001_01C20C8D.4E2A0476 Content-Type: text/plain; charset="windows-1255" Hello, The mediasize internet-draft that I have submitted yesterday has a formatting problem where double-quotation characters (") show as strange graphics or special european languages symbols in some cases. I appologize for this error !!! I have submitted a fixed version to the repository and hopefully it will be available soon. In the meantime, I am submitting the fixed version here as well. <> Regards, Ari Erev ------_=_NextPart_001_01C20C8D.4E2A0476 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Some wrong characters in the submitted SMTP MediaSize = extension

Hello,

The mediasize internet-draft that I = have submitted yesterday has a formatting problem where = double-quotation characters (") show as strange graphics or = special european languages symbols in some cases.

I appologize for this error !!!

I have submitted a fixed version to = the repository and hopefully it will be available soon.

In the meantime, I am submitting the = fixed version here as well.

= <<draft-shveidel-mediasize-00.txt>>
Regards,
Ari Erev

------_=_NextPart_001_01C20C8D.4E2A0476-- ------_=_NextPart_000_01C20C8D.4E2A0476 Content-Type: text/plain; name="draft-shveidel-mediasize-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-shveidel-mediasize-00.txt" = V.Shveidel=20 Internet Draft = A.Erev=20 Document: draft-shveidel-mediasize-01.txt = Comverse=20 Expires: 2003 = June 2002=20 =20 =20 SMTP Service Extension for message Media Size = declaration=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full = conformance with=20 all provisions of Section 10 of RFC2026.=20 =20 This RFC specifies an IAB standards track protocol = for the Internet=20 community, and requests discussion and suggestions = for improvements.=20 Please refer to the current edition of the "IAB = Official Protocol=20 Standards" for the standardization state and status = of this=20 protocol. Distribution of this memo is unlimited.=20 =20 The list of current Internet-Drafts can be accessed = at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be = accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 Abstract=20 =20 This memo defines an extension to the SMTP service = whereby an SMTP=20 client and server may interact to give the server an = opportunity to=20 decline to accept a message (perhaps temporarily) = based on the=20 client's estimate of the general message size and = sizes of media=20 parts the message contains.=20 =20 [9] lists a number of issues and requirements for the = use of=20 internet messaging in the context of Unified = Messaging and Telephone=20 User Interface. This memo elaborates and suggests an = implementation=20 for chapter 3.2 of [9].=20 =20 This memo extends facilities of "SMTP Service = Extension for Message=20 Size Declaration" [3]. As such, the authors of this = memo used=20 portions of the text in [3] as a basis for this memo. = =20 =20 Table of Contents=20 =20 Status of this = Memo................................................1=20 = Abstract...........................................................1=20 1. = Introduction...................................................2=20 2. Framework for the Per Media Size Declaration = Extension.........3=20 3. The Message Media Size Declaration service = extension...........4=20 4. = Definitions....................................................5=20 =20 Shveidel/Erev Internet draft - Expires February = 2003 1 =0C SMTP Per Media Size Declaration = June 2002=20 =20 =20 =20 5. The extended MAIL = command......................................5=20 5.1 Server action on receipt of the extended MAIL = command..........6=20 5.2 Client action on receiving response to extended = MAIL command...7=20 5.3 Messages containing media parts larger than the = declared media=20 = size...............................................................7=20 6. Minimal = usage..................................................8=20 7. = Example........................................................8=20 8. Security = considerations........................................9=20 9. IANA = Considerations............................................9=20 9.1. Message Context size units = Registrations.....................10=20 9.2. Registration = Template........................................10=20 10. = References....................................................11=20 11. Author's = Addresses............................................11=20 =20 =20 1. Introduction=20 =20 The MIME extensions to the Internet message protocol = provide for the=20 transmission of many kinds of data which were = previously unsupported=20 in Internet mail. One expected result of the use of = MIME is that=20 SMTP will be expected to carry a much wider range of = message sizes=20 and message media types than was previously the case. = This has an=20 impact on the amount of resources (e.g., disk space) = required by a=20 system acting as a server.=20 =20 This memo uses the mechanism defined in [5] to define = extensions to=20 the SMTP service whereby a client ("sender-SMTP") may = declare the=20 general size of a particular message and a per media = size to a server=20 ("receiver-SMTP"), after which the server may = indicate to the client=20 that it is or is not willing to accept the message = based on the=20 declared =91per-media size=92 of the message and = whereby a server=20 ("receiver-SMTP") may declare the maximum = =91per-media size=92 for a=20 message it is willing to accept from a client = ("sender-SMTP").=20 This memo extends facilities of "SMTP Service = Extension for Message=20 Size Declaration" [3].=20 =20 As mentioned above, the proposed extension allows an = SMTP client and=20 an SMTP server to coordinate transmission of a = message based on its=20 size, classified by specific media type(s). This = allows the server=20 to manage quota per media or per message-context (see = [6]). =20 =20 There are basically two alternatives to manage = per-media/context=20 quota: (1) Associate the media size of the whole = message to a=20 "Message-Context" category (see [6]). Or, (2) = Associate each body=20 part to a specific Quota class, based on its = content/media type. (=20 =20 An example of (1) is a "voice-message" = message-context, which may=20 include a text attachment. Both the voice and the = text parts will be=20 accounted on the "voice-message" Quota.=20 =20 Shveidel Informational - Expires February 2003 = 2 =0C SMTP Per Media Size Declaration = June 2002=20 =20 =20 =20 An example of (2) is a "video message" that contains = a body part=20 with video content-type and another body part with = audio content- type =96 each of them accounted to different quota = classes "video" and=20 "audio" respectively.=20 An implementation may decide which of the above = alternatives to use.=20 =20 =20 2. Framework for the Per Media Size Declaration = Extension=20 =20 The following service extension is therefore defined: = =20 (1) The name of the SMTP service extension is = "Message MediaSize=20 Declaration";=20 =20 (2) The EHLO keyword value associated with this = extension is=20 "MEDIASIZE";=20 =20 (3) Some optional parameters are allowed with this = EHLO keyword.=20 Each parameter is a string indicating the fixed = maximum size of=20 media parts of the message in special units that = the server will=20 accept. The syntax of the parameter is as follows, = using the=20 augmented BNF notation of [2]:=20 =20 mediasize-params ::=3D [*(SP media_size_dsc)]=20 =20 media_size_dsc ::=3D media:maxsize unit = *([;maxsize unit])=20 =20 media ::=3D (ALPHA / DIGIT) *(ALPHA / DIGIT / = "-")=20 =20 maxsize ::=3D [1*(DIGIT)]=20 =20 unit ::=3D ALPHA *(ALPHA / "-")=20 =20 =20 A maxsize value of 0 (zero) indicates that no = fixed maximum=20 message media size is in force. If some parameter = is omitted no=20 information is conveyed about the server's fixed = maximum message=20 size for corresponding media. =20 =20 (4) One optional parameter using the keyword "SIZE" = is added to the =20 MAIL FROM command. The value associated with this = parameter is a=20 string indicating the general size and the = per-media size of the=20 message that is to be transmitted. The syntax of = the value is as=20 follows, using the augmented BNF notation of [2]:=20 =20 =20 mediasize-value ::=3D = general_size[*(;media_size)]=20 =20 general_size ::=3D size-value=20 =20 media_size ::=3D [media:size-value unit]=20 =20 =20 Shveidel Informational - Expires February 2003 = 3 =0C SMTP Per Media Size Declaration = June 2002=20 =20 =20 =20 media ::=3D (ALPHA / DIGIT) *(ALPHA / DIGIT / = "-")=20 =20 unit ::=3D ALPHA *(ALPHA / "-")=20 =20 size-value ::=3D 1*(DIGIT)=20 =20 =20 (5) no additional SMTP verbs are defined by this = extension.=20 =20 The remainder of this memo specifies how support = for the extension =20 affects the behavior of an SMTP client and server. = =20 =20 3. The Message Media Size Declaration service extension = =20 An SMTP server may have a fixed upper limit not only = on general=20 message size but also an upper limit on each media = type, which may be=20 contained in the message. Any attempt by a client to = transfer a=20 message containing a media part whose size is larger = than this fixed=20 upper limit will fail. In addition, a server = normally has limited=20 space for storing incoming messages. Transfer of a = message may=20 therefore fail due to lack of storage space for a = specific media, but=20 may succeed at a later time.=20 =20 A client using the SMTP protocol defined in [1] (with = no extensions)=20 or the SMTP protocol with "Message Size Declaration = service=20 extension" [3] can only be informed of such failures = after=20 transmitting the entire message to the server (which = discards the=20 transferred message). If, however, both client and = server support the=20 Message Media Size Declaration service extension, = such conditions may=20 be detected before any transfer is attempted.=20 =20 =20 An SMTP client wishing to relay large media content = may issue the=20 EHLO command to start an SMTP session, to determine = if the server=20 supports any of several service extensions. If the = server responds=20 with code 250 to the EHLO command, and the response = includes the EHLO=20 keyword value MEDIASIZE, then the Message Media Size = Declaration=20 extension is supported.=20 =20 If a string of parameters follows the MEDIASIZE = keyword value of the=20 EHLO response, each of the parameters indicates the = maximal size and=20 units for a specific media type of the message, or = parts of the=20 message, that the server is willing to accept. Any = attempt by a=20 client to transfer a message containing a media part = that is larger=20 than this limit will be rejected with a permanent = failure (552) reply=20 code.=20 If the SMTP server has no fixed maximum size = limitation for a=20 specific media, it still should include this media = type in the=20 MEDIASIZE EHLO response (with the maximum size set to = 0) so that the=20 client knows that this media type is supported by the = server and the=20 media unit(s) supported in the context of MEDIASIZE = processing.=20 =20 Shveidel Informational - Expires February 2003 = 4 =0C SMTP Per Media Size Declaration = June 2002=20 =20 =20 =20 =20 A server that supports the Message Media Size = Declaration extension=20 will accept the extended version of the MAIL command = described below.=20 When supported by the server, a client may use the = extended MAIL=20 command (instead of the MAIL command as defined in = [1] and extension=20 defined in [3]) to declare an estimate of the size of = a message it=20 wishes to transfer. The server may then return an = appropriate error=20 code if it determines that an attempt to transfer a = message with=20 media part of that size would fail.=20 =20 4. Definitions=20 =20 The per media message size is defined as the sequence = of general=20 message size (as it is defined in [3]), and one or = more media size=20 items describing duration of media parts of the = message. A Media size=20 item is defined as the sequence of the character ";", = media name, the=20 character ":", media size (or duration) and = immediately following it,=20 the unit measurement name. Media name is defined as = alphabetical=20 string and is subject for future standardization. = Size is defined as=20 number of octets. Measurement unit is defined as = alphabetical string=20 and is subject for future standardization.=20 =20 The fixed maximum message per media size is defined = as the set of the=20 fixed maximum message sizes for specific media = potentially contained=20 in the message that a server is ever willing to = accept. An attempt=20 to transfer any message with media part larger than = the fixed maximum=20 for this media will always fail.=20 The fixed maximum message media size may be an = implementation=20 artifact of the SMTP server, or it may be chosen by = the administrator=20 of the server.=20 The fixed maximum size for specific media is defined = as the sequence=20 of media name, the character ":" and one or more = pairs of media size=20 followed by the measurement unit. Pairs are delimited = by a ";". Each=20 pair gives an alternative for media size/duration = representation=20 supported by the server. =20 =20 The declared message media size is defined as a = client's estimate of=20 the message media size for a particular message.=20 =20 5. The extended MAIL command=20 =20 The extended MAIL command is issued by a client when = it wishes to=20 inform a server of the media size(s) of the message = to be sent. The=20 extended MAIL command is identical to the MAIL = command as defined in=20 [3], except that a SIZE parameter contains not only = general message=20 size but also the media size (or duration).=20 =20 The complete syntax of thee extended command is = defined in [5]. The=20 esmtp-keyword is "SIZE" and the syntax for = esmtp-value is given by=20 the syntax for mediasize-value shown above.=20 =20 =20 Shveidel Informational - Expires February 2003 = 5 =0C SMTP Per Media Size Declaration = June 2002=20 =20 =20 =20 The value associated with the SIZE parameter is a = string=20 representation of the declared message media size in = specific units=20 for each media type. General message size is = represented as it is=20 defined in [3].=20 =20 Ideally, the declared message media size is equal to = the true message=20 size. However, since exact computation of the message = media size may=20 be infeasible, the client may use a = heuristically-derived estimate.=20 Such heuristics should be chosen so that the declared = message media=20 size is larger than the actual message size.=20 =20 NOTE: Servers MUST NOT use the SIZE parameter to = determine end of=20 content in the DATA command.=20 =20 5.1 Server action on receipt of the extended MAIL = command=20 =20 Upon receipt of an extended MAIL command containing a = media extended=20 SIZE parameter, a server should determine whether the = declared=20 general message size exceeds its (current) fixed = maximum message size=20 and whether declared media size(s) exceed = corresponding fixed maximum=20 media sizes. If the declared general message size = and all of=20 declared media sizes are smaller than the = corresponding fixed maximum=20 message sizes, the server may also wish to determine = whether=20 sufficient resources are available to buffer a = message of the=20 declared media size and to maintain it in stable = storage, until the=20 message can be delivered or relayed to each of its = recipients.=20 =20 A server may respond to the extended MAIL command = with any of the=20 error codes defined in [1] and [3] for the MAIL = command. In=20 addition, one of the following error codes may be = returned:=20 =20 (1) If the server does not support the measurement = unit for a=20 specific media that was specified by the client in = the MAIL=20 command, the server should respond with code "501 = Syntax error in=20 parameter, illegal unit name" =20 =20 (2) If the server currently lacks sufficient = resources to accept a=20 message of the indicated media size, but may be = able to accept the=20 message at a later time, it should respond with = code "452=20 insufficient system media-specific storage".=20 =20 (3) If the indicated per media size is larger than = the server's fixed=20 maximum message per media size, the server should = respond with=20 code "552 message media size exceeds fixed maximum = message media=20 size".=20 =20 A server is permitted, but not required, to accept = a message,=20 which is, in fact, larger than declared in the = extended MAIL=20 command, such as might occur if the client = employed a size- estimation heuristic which was inaccurate = (produced a lower=20 result).=20 =20 =20 Shveidel Informational - Expires February 2003 = 6 =0C SMTP Per Media Size Declaration = June 2002=20 =20 =20 =20 =20 =20 5.2 Client action on receiving response to extended MAIL = command=20 =20 =20 (1) If the code "452 insufficient system media = storage" is returned,=20 the client should next send either a RSET command = (if it wishes to=20 attempt to send other messages) or a QUIT command. = The client=20 should then repeat the attempt to send the message = to the server=20 at a later time.=20 =20 (2) If the code "552 message media size exceeds fixed = maximum message=20 media size" is received, the client should = immediately send either=20 a RSET command (if it wishes to attempt to send = additional=20 messages), or a QUIT command. The client should = then declare the=20 message undeliverable and return appropriate = notification to the=20 sender (if a sender address was present in the = MAIL command).=20 =20 A successful (250) reply code in response to the = extended MAIL=20 command does not constitute an absolute guarantee = that the message=20 transfer will succeed. SMTP clients using the = extended MAIL=20 command must still be prepared to handle both = temporary and=20 permanent error reply codes (including codes 452 = and 552), either=20 immediately after issuing the DATA command, or = after transfer of=20 the message.=20 =20 5.3 Messages containing media parts larger than the = declared media size.=20 =20 Once a server has agreed (via the extended MAIL = command) to accept a=20 message of a particular media size, it should not = return a 552 reply=20 code after the transfer phase of the DATA command, = unless the actual=20 per media size of the message transferred is greater = than the=20 declared message per media size. A server may also = choose to accept a=20 message containing media parts which are somewhat = larger than the=20 declared media size.=20 =20 A client is permitted to declare a message to be = smaller than its actual per media size. However, in this case, a = successful (250=20 reply code is no assurance that the server will = accept the message or=20 has sufficient resources to do so. The server may = reject such a=20 message after its DATA transfer.=20 =20 5.4 Per-recipient rejection based on message per media = size.=20 =20 A server that implements this extension may return a = 452 or 552 reply=20 code (as it is explained in 5.1) in response to a = RCPT command, based=20 on its unwillingness to accept a message of the = declared per media=20 size for a particular recipient.=20 =20 (1) If a 452 code is returned, the client is expected = to requeue the=20 message for later delivery to the same recipient.=20 =20 =20 Shveidel Informational - Expires February 2003 = 7 =0C SMTP Per Media Size Declaration = June 2002=20 =20 =20 =20 (2) If a 552 code is returned, the client is expected = to refrain from=20 any later retry delivery to the same recipient.=20 =20 6. Minimal usage=20 =20 A "minimal" client may use this extension to simply = compare the=20 (perhaps estimated) per media size of the message = that it wishes to=20 relay, with the server's fixed maximum message per = media size (from=20 the parameter to the MEDIASIZE keyword in the EHLO = response), to=20 determine whether the server will ever accept the = message. Such an=20 implementation need not declare message per media = size via the=20 extended MAIL command. However, neither will it be = able to discover=20 temporary limits on message media size due to server = resource=20 limitations, nor per-recipient limitations on message = media size.=20 =20 A "minimal" server that employs this service = extension may simply use=20 the MEDIASIZE keyword value to inform the client of = the size of the=20 largest media parts of message it will accept, or to = inform the=20 client that there is no fixed limit on message media = sizes. Such a=20 server must accept the extended MAIL command and = return a 552 reply=20 code if the client's declared media size exceeds its = fixed media size=20 limit (if any), but it need not detect "temporary" = limitations on=20 message media size.=20 =20 The string parameters to the EHLO MEDIASIZE keyword = are optional. If=20 some parameter is omitted entirely it indicates that = the server does=20 not advertise a fixed maximum for this media size. A = server that=20 returns the MEDIASIZE keyword with no parameter or = with omitted=20 parameter for specific media in response to the EHLO = command should=20 not issue a positive (250) response to an extended = MAIL command=20 containing a media-extended SIZE specification = without first checking=20 to see if sufficient resources are available to = transfer a message of=20 the declared media sizes, and to retain it in stable = storage until it=20 can be relayed or delivered to its recipients. If = possible, the=20 server should actually reserve sufficient message = storage space to=20 transfer the message.=20 =20 7. Example=20 =20 The following example illustrates the use of per = media size=20 declaration with some permanent and temporary = failures.=20 =20 =20 S: =20 C: =20 S: 220 il-tlv-vis.icomverse.com ESMTP Service = ready=20 C: EHLO merlot.comverse.com=20 S: 250- merlot.comverse.com=20 S: 250-EXPN=20 S: 250-HELP=20 S: 250 SIZE 1000000=20 =20 Shveidel Informational - Expires February 2003 = 8 =0C SMTP Per Media Size Declaration = June 2002=20 =20 =20 =20 S: 250 MEDIASIZE video:100sec;10000kb = fax:20pages;2000kb=20 voice:10sec=20 C: MAIL FROM: = SIZE=3D80000;video:7sec;fax:3pages=20 S: 250 Address Ok.=20 C: RCPT TO:=20 S: 250 v@comverse.com OK; can accept=20 80000;video:7sec;fax:3pages =20 C: RCPT TO:=20 S: 452 insufficient system media storage (fax): = x@comverse.com=20 C: DATA=20 S: 354 Send message, ending in CRLF.CRLF.=20 ...=20 C: .=20 S: 250 OK=20 C: QUIT=20 S: 250 Goodbye=20 =20 =20 8. Security considerations=20 =20 The media size declaration extensions described in = this memo can =20 conceivably be used to facilitate crude service = denial attacks. =20 Specifically, both the information contained in the = SIZE parameter =20 and use of the extended MAIL command make it somewhat = quicker and=20 easier to devise an efficacious service denial = attack.=20 =20 It is recommended that an implementation supports = internal mapping=20 between media size units and compares the declared = size and the=20 actually received size (if in different units) to = validate that the=20 two relate to each other reasonably. This should = prevent cases where=20 the declared size (expressed in some unit) defers = from the actual=20 sent size (possibly measured in another unit).=20 Describing the mapping algorithm (which may be = dependent on specific=20 file formats and encoding schemes) is out of the = scope of this draft.=20 =20 Other than that this extension does not create any = vulnerability that=20 has not existed with SMTP or with SMTP with the = original SIZE=20 extension. =20 =20 =20 9. IANA Considerations =20 =20 To promote interoperability and coherent = interpretations of=20 different media types, a central repository for = well-known media=20 types and possible measurement units should be = maintained. =20 =20 As mentioned above (see "Introduction"), there are = two alternatives=20 to manage per-media/context quota. When media size is = associated=20 with the "Message-Context" (i.e., the whole message = is considered as=20 one entity for quota purposes) =96 then the central = repository is the=20 IANA-managed Message-Context repository.=20 =20 Shveidel Informational - Expires February 2003 = 9 =0C SMTP Per Media Size Declaration = June 2002=20 =20 =20 =20 When per-media quota is calculated based on each = media part element=20 in the message (possibly using multiple media quota = per message) the=20 recommended registry of media type to use is the = IANA-managed=20 "Content-Type" registry =96 specifically, the type = (as opposed to the=20 sub-type) in the content-type value.=20 =20 In both cases, there is a need to register the = available units to go=20 with the message-context or content-type identifying = the media. The=20 following is a suggested list for initial values for = registration.=20 =20 9.1. Message Context size units Registrations =20 =20 Internet Message-Context Size Units =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =20 =20 Media Type (referenced Possible Unit(s) =20 Message-Context value) first is default) = Reference=20 ----------------------- --------------------- = -----------=20 voice-message "kb" (kilobytes) = this RFC=20 "sec" (seconds)=20 = =20 fax-message "kb"(kilobytes) = this RFC=20 "pages"=20 =20 video-message "kb"(kilobytes) = this RFC=20 "sec" (seconds)=20 = =20 text-message "kb"(kilobytes) = this RFC =20 =20 =20 9.2. Registration Template =20 =20 =0D =0D =0D = =20 In the following template, a pipe symbol, "|", = precedes instructions=20 or other helpful material. Be sure to replace = ""=20 with the media type name you are defining. =20 =20 Media Type name: =20 =20 |Referenced Message-Context (or Content-Type) = value =20 =20 Default measurement unit:=20 | Name of default measurement unit for the = media (not longer=20 | than 10 characters)=20 =20 Possible measurement units:=20 | List of possible names of measurement unit = for the media=20 | type (each name must be not longer than 10 = characters) =20 =20 Person & email address to contact for further = information: =20 =20 Shveidel Informational - Expires February 2003 = 10 =0C SMTP Per Media Size Declaration = June 2002=20 =20 =20 =20 | Name & e-mail =20 =20 =20 10. References=20 =20 [1] Klensin J, "Simple Mail Transfer Protocol", = STD 10, RFC 2821,=20 AT&T Laboratories, April 2001.=20 =20 [2] Crocker, D., "Standard for the Format of ARPA = Internet Text=20 Messages", STD 11, RFC 822, UDEL, August 1982. = =20 [3] J. Klensin, WG Chair, "SMTP Service Extension = for Message=20 Size Declaration", RFC 1427, University of = Tennessee,=20 February 1993.=20 =20 [4] Klensin, J., WG Chair, Freed, N., Editor, = Rose, M., Stefferud,=20 E., and D. Crocker, "SMTP Service Extensions" = RFC 1425, United=20 Nations University, Innosoft International, = Inc., Dover Beach=20 Consulting, Inc., Network Management = Associates, Inc., The =20 Branch Office, February 1993.=20 =20 [5] J. Klensin, WG Chair, " SMTP Service = Extensions ", RFC 1869,=20 Brandenburg Consulting, November 1995.=20 =20 [6] E. Burger, C. Eliot, G. Klyne, E. Candell, = "Message Context =20 for Internet Mail", Internet draft, Microsoft, = Comverse,=20 Baltimore Technologies, SnowShore Networks = June 2001.=20 =20 [7] Alvestrand, H. and T. Narten, "Guidelines for = Writing an IANA=20 Considerations Section in RFCs", BCP 26, RFC = 2434, October=20 1998. =20 =20 [8] J. Myers, "IMAP4 QUOTA extension", RFC 2087, = January 1997.=20 =20 [9] Greg Vaudreuil, "Messaging Profile For = Telephone-based =20 Messaging Clients". =20 = http://www.ietf.org/internet-drafts/draft-vaudreuil-um-=20 issues-00.txt=20 =20 =20 =20 11. Author's Addresses=20 =20 Vladimir Shveidel=20 Comverse =20 29 Habarzel St.=20 Tel-Aviv 69710=20 Israel=20 EMail: Vladimir.Shveidel@comverse.com=20 =20 =20 Ari Erev=20 =20 Shveidel Informational - Expires February 2003 = 11 =0C SMTP Per Media Size Declaration = June 2002=20 =20 =20 =20 Comverse=20 29 Habarzel St.=20 Tel-Aviv 69710=20 Israel=20 EMail: Ari.Erev@comverse.com=20 =20 =20 =20 Shveidel Informational - Expires February 2003 = 12 =0C ------_=_NextPart_000_01C20C8D.4E2A0476-- - 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 Sun Jun 9 03:33:12 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id g597XAL27982 for um-outgoing; Sun, 9 Jun 2002 03:33:10 -0400 (EDT) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from il-tlv-smtpout1.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g597X0B27942 for ; Sun, 9 Jun 2002 03:33:01 -0400 (EDT) Received: from il-tlv-mbdg2.icomverse.com (il-tlv-mbdg2.comverse.com [10.115.244.42]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id g597WuX32208; Sun, 9 Jun 2002 10:32:57 +0300 Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id ; Sun, 9 Jun 2002 10:33:41 +0300 Message-ID: <7D4344E32B34D511A6500002A560C60202FC11C0@il-tlv-mail4.comverse.com> From: "Erev, Ari" To: "'Dan Wing'" Cc: ietf-smtp@imc.org, vpim@lists.neystadt.org, um@snowshore.com, "Shveidel, Vladimir" Subject: [UM] RE: I-D ACTION:draft-shveidel-mediasize-00.txt Date: Sun, 9 Jun 2002 10:33:39 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20F87.F9651C70" 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_01C20F87.F9651C70 Content-Type: text/plain; charset="iso-8859-1" Hello Dan, First - an administrative suggestion. I suggest that discussion of this I-D is done in the UM mailing list (um@snowshore.com) so as not to duplicate the discussion on all the above lists. I am still sending my reply to all the three lists but suggest to limit future communications only the UM list. My answers inside. Regards, Ari > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, June 07, 2002 12:59 AM > To: Shveidel, Vladimir; Erev, Ari > Cc: ietf-smtp@imc.org; vpim@lists.neystadt.org; um@snowshore.com > Subject: RE: I-D ACTION:draft-shveidel-mediasize-00.txt > > > > Title : SMTP Service Extension for message Media Size > > declaration > > Author(s) : V. Shveidel, A. Erev > > Filename : draft-shveidel-mediasize-00.txt > > Pages : 12 > > Date : 04-Jun-02 > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-shveidel-mediasize-00.txt > > Hi. > > I'm unable to understand the underlying architecture that caused > you to create this I-D. What architecture of a message store > prevents it from storing, say, 1Mb of audio but allows it to > store 1Mb of plain text? As stated in the 'abstract' section - this I-D is one of the issues and requirements raised by draft-vaudreuil-um-issues-00.txt (see: 3.2 in it). Here is a relevant part from draft-vaudreuil-um-issues-00.txt: It is common in a unified messaging system to offer separate quota's for each of several message contexts to avoid the condition where a flood of email fills the mailbox and prevents the subscriber from receiving voice messages via the telephone. It is necessary to extend the protocols to support the reporting of the "mailbox full" status based on the context of the submitted message. While the preliminary text in draft-vaudreuil-um-issues-00.txt only talked about 'Quota by context' this draft expands a bit so as to (optionally) allow 'quota by media' - where a message of a certain context may hold more than one media type. We hoped that a discussion on the list will consider the enhancement and decide whether it is required - or the less flexible 'quota by context' is enough. > > How is an SMTP client supposed to map the MIME types of a > message to the media types (voice-message, fax-message, > video-message, text-message) that you enumerate in section > 9.1 of your I-D? What of MIME types that the SMTP client > doesn't recognize - how are they to be handled? > This I-D builds on some "work-in-progress' done in VPIM, and specifically on the "Message-Context" I-D (draft-ietf-vpim-hint-08.txt) which is assumed to be used by a "Unified- Messaging-enabled" SMTP client. A non-conforming SMTP client will still work but will not get the benefit of knowning _in advance_ whether the server is ready to accept this message due to its media/context size. This is similar to an SMPT client that does not use the SMTP Size Extension. > I found no registration facility for the units used in > examples in your I-D (kb, sec, pages). Unfortunately, the > mechanism to convert or validate one unit to another is > vague. Further, the premise of the entire document is that > an architecture of an SMTP message store doesn't permit > it to store "large" media parts -- yet, the size of a > media part isn't indicated by its duration (seconds) or > length (pages). Rather, only a count of bytes is > meaningful. > As for the registration facitiliy - I think we suggested to consider two options: either to extend the "Message-context" registration with these units, or to extend the 'content-type' registration with these units. As to the mechanism to convert/validate one unit to another - I agree it is somewhat vague. This is because we assumed it to be an implementation issue and not a protocol definition. For example, in the case of voice-mail systems, they usually support a limited number of formats/codecs and then the conversion is more straight forward. I agree that the general case of supporting all sorts of media and encodings is much more complicated and (IMHO) is out of the scope of this I-D. > If you could help me understand the background for this > I-D, I'll be happy to discuss some other questions I have > with this document. As written above - the context is: draft-vaudreuil-um-issues-00.txt. > > -d > ------_=_NextPart_001_01C20F87.F9651C70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-shveidel-mediasize-00.txt

Hello Dan,

First - an administrative suggestion. I suggest that = discussion of this I-D is done in the UM mailing list = (um@snowshore.com) so as not to duplicate the discussion on all the = above lists.

I am still sending my reply to all the three lists = but suggest to limit future communications only the UM list.

My answers inside.

Regards,
Ari

> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com]
> Sent: Friday, June 07, 2002 12:59 AM
> To: Shveidel, Vladimir; Erev, Ari
> Cc: ietf-smtp@imc.org; vpim@lists.neystadt.org; = um@snowshore.com
> Subject: RE: I-D = ACTION:draft-shveidel-mediasize-00.txt
>
>
> >     Title   =         : SMTP Service Extension for = message Media Size
> = >           &n= bsp;           &n= bsp;   declaration
> >     = Author(s)       : V. Shveidel, A. = Erev
> >     = Filename        : = draft-shveidel-mediasize-00.txt
> >     Pages   =         : 12
> >     Date    =         : 04-Jun-02
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-shveidel-med= iasize-00.txt
>
> Hi.
>
> I'm unable to understand the underlying = architecture that caused
> you to create this I-D. What architecture = of a message store
> prevents it from storing, say, 1Mb of audio but = allows it to
> store 1Mb of plain text?

As stated in the 'abstract' section - this I-D is one = of the issues and requirements raised by = draft-vaudreuil-um-issues-00.txt (see: 3.2 in it).

Here is a relevant part from = draft-vaudreuil-um-issues-00.txt:

It is common in a unified messaging system to offer = separate quota's for
each of several message contexts to avoid the = condition where a flood of
email fills the mailbox and prevents the subscriber = from receiving voice
messages via the telephone. It is necessary to = extend the protocols to
support the reporting of the "mailbox = full" status based on the context
of the submitted message.

While the preliminary text in = draft-vaudreuil-um-issues-00.txt only talked about 'Quota by context' = this draft expands a bit so as to (optionally) allow 'quota by media' - = where a message of a certain context may hold more than one media type.<= /FONT>

We hoped that a discussion on the list will consider = the enhancement and decide whether it is required - or the less = flexible 'quota by context' is enough.

>
> How is an SMTP client supposed to map the MIME = types of a
> message to the media types (voice-message, = fax-message,
> video-message, text-message) that you enumerate = in section
> 9.1 of your I-D? What of MIME types that = the SMTP client
> doesn't recognize - how are they to be = handled?
>

This I-D builds on some "work-in-progress' done = in VPIM, and specifically on the "Message-Context" I-D = (draft-ietf-vpim-hint-08.txt) which is assumed to be used by a = "Unified- Messaging-enabled" SMTP client. A non-conforming = SMTP client will still work but will not get the benefit of knowning = _in advance_ whether the server is ready to accept this message due to = its media/context size. This is similar to an SMPT client that does not = use the SMTP Size Extension.

> I found no registration facility for the units = used in
> examples in your I-D (kb, sec, pages). = Unfortunately, the
> mechanism to convert or validate one unit to = another is
> vague. Further, the premise of the entire = document is that
> an architecture of an SMTP message store = doesn't permit
> it to store "large" media parts -- = yet, the size of a
> media part isn't indicated by its duration = (seconds) or
> length (pages). Rather, only a count of = bytes is
> meaningful.
>
As for the registration facitiliy - I think we = suggested to consider two options: either to extend the = "Message-context" registration with these units, or to extend = the 'content-type' registration with these units.

As to the mechanism to convert/validate one unit to = another - I agree it is somewhat vague. This is because we assumed it = to be an implementation issue and not a protocol definition. For = example, in the case of voice-mail systems, they usually support a = limited number of formats/codecs and then the conversion is more = straight forward. I agree that the general case of supporting all sorts = of media and encodings is much more complicated and (IMHO) is out of = the scope of this I-D.

> If you could help me understand the background = for this
> I-D, I'll be happy to discuss some other = questions I have
> with this document.
As written above - the context is: = draft-vaudreuil-um-issues-00.txt.

>
> -d
>

------_=_NextPart_001_01C20F87.F9651C70-- - 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 Jun 10 11:27:01 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id g5AFQuF01839 for um-outgoing; Mon, 10 Jun 2002 11:26:56 -0400 (EDT) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g5AFQsB01834 for ; Mon, 10 Jun 2002 11:26:54 -0400 (EDT) Reply-To: From: "Eric Burger" To: "IETF LEMONAID" Subject: [UM] Draft BOF Charter Date: Mon, 10 Jun 2002 11:28:01 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-um@snowshore.com Precedence: bulk If we're going to get work done, we need a charter. Here is something to pick apart. The most important issues are... The name and chairs. Unless we want a Friday afternoon slot in Yokohama, we need to get this to Ned shortly. Thanks. -- - Eric BOF Name ======== License to Enhance Messaging Oriented Network Access for Internet Devices (LEMONAID) BOF co-chairs ============= Looking for volunteers; send me an e-mail! Mailing List ============ General Discussion: um@snowshore.com To Subscribe: majordomo@snowshore.com, In Body: subscribe um Archive: http://flyingfox.snowshore.com/um_archive/maillist.html Proposed Charter ================ Internet Unified Messaging brings together the body of work currently chartered in VPIM, IFAX, IMAPEXT, and other IETF work groups. The goal is to provide a single infrastructure, mailbox, and set of interfaces for a user to get, respond to, and manipulate all of their messages from a collection of clients with varying capabilities, no matter what the media or source. Initial work, in the VPIM and FAX WG for example, focused on the server and network interactions and has resulted in a rich base of Internet Mail standards to support unified messaging. Now that this work is stable in the industry, and with the proliferation of smaller and often mobile Internet devices, the issues of client access to Internet Mail need to be addressed. Given the potentially broad scope of "unified messaging", this BOF will focus on the following work items: 1. Enhance message retrieval protocols to satisfy the requirements for low-latency playback. 2. Extend message deposit and retrieval to satisfy the requirements for low-bit-rate transports and limited-processing devices, such as mobile endpoints. 3. Create appropriate message notification protocols to satisfy the need of reporting the status of different message contexts. The BOF will coordinate its efforts with the 3GPP TSG T WG2 SWG3 Messaging and other appropriate entities, such as the W3C Mulitmodal interaction Activity . While there is obvious synergy, given the end-of-life of the VPIM and FAX work groups and the similar membership, the BOF does not expect to coordinate with those groups. If IMAP-EXT gets rechartered, then the BOF will coordinate the LEMONAID requirements with IMAP-EXT. Otherwise, this BOF will consider extensions to IMAP for the purposes of LEMONAID support. Reading List ============ - draft-burger-imap-chanuse-00.txt - draft-burger-um-reqts-00.txt - draft-neystadt-imap-status-counters-00.txt - draft-shapira-snap-03.txt - draft-shveidel-mediasize-00.txt - draft-vaudreuil-futuredelivery-00.txt - draft-vaudreuil-um-issues-00.txt Deep background reading - draft-nerenberg-imap-channel-01.txt - draft-nerenberg-imap-binary-02.txt Milestones ========== Oct 2002 - LEMONAID Requirements Dec 2002 - Notification protocol Mar 2003 - IMAP extensions for VM playback Mar 2003 - IMAP extensions for mobile devices - 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 Jun 10 12:32:25 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id g5AGWOP03173 for um-outgoing; Mon, 10 Jun 2002 12:32:24 -0400 (EDT) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g5AGWNB03168; Mon, 10 Jun 2002 12:32:23 -0400 (EDT) Received: from co7010exch003u.wins.lucent.com (h135-39-1-23.lucent.com [135.39.1.23]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5AGWGl21275; Mon, 10 Jun 2002 12:32:17 -0400 (EDT) Received: by co7010exch003u.milehi.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 10:32:16 -0600 Message-ID: From: "Vaudreuil, Greg M (Greg)" To: eburger@snowshore.com, IETF LEMONAID Subject: RE: [UM] Draft BOF Charter Date: Mon, 10 Jun 2002 10:32:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-um@snowshore.com Precedence: bulk I believe a key thrust is the ability for endpoint clients to gain higher level of network-based messaging service.... so I suggest: License to Enhance Messaging Oriented Network Access for Diverse Endpoints (LEMONADE) Greg V. -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Monday, June 10, 2002 10:28 AM To: IETF LEMONAID Subject: [UM] Draft BOF Charter If we're going to get work done, we need a charter. Here is something to pick apart. The most important issues are... The name and chairs. Unless we want a Friday afternoon slot in Yokohama, we need to get this to Ned shortly. Thanks. -- - Eric BOF Name ======== License to Enhance Messaging Oriented Network Access for Internet Devices (LEMONAID) BOF co-chairs ============= Looking for volunteers; send me an e-mail! Mailing List ============ General Discussion: um@snowshore.com To Subscribe: majordomo@snowshore.com, In Body: subscribe um Archive: http://flyingfox.snowshore.com/um_archive/maillist.html Proposed Charter ================ Internet Unified Messaging brings together the body of work currently chartered in VPIM, IFAX, IMAPEXT, and other IETF work groups. The goal is to provide a single infrastructure, mailbox, and set of interfaces for a user to get, respond to, and manipulate all of their messages from a collection of clients with varying capabilities, no matter what the media or source. Initial work, in the VPIM and FAX WG for example, focused on the server and network interactions and has resulted in a rich base of Internet Mail standards to support unified messaging. Now that this work is stable in the industry, and with the proliferation of smaller and often mobile Internet devices, the issues of client access to Internet Mail need to be addressed. Given the potentially broad scope of "unified messaging", this BOF will focus on the following work items: 1. Enhance message retrieval protocols to satisfy the requirements for low-latency playback. 2. Extend message deposit and retrieval to satisfy the requirements for low-bit-rate transports and limited-processing devices, such as mobile endpoints. 3. Create appropriate message notification protocols to satisfy the need of reporting the status of different message contexts. The BOF will coordinate its efforts with the 3GPP TSG T WG2 SWG3 Messaging and other appropriate entities, such as the W3C Mulitmodal interaction Activity . While there is obvious synergy, given the end-of-life of the VPIM and FAX work groups and the similar membership, the BOF does not expect to coordinate with those groups. If IMAP-EXT gets rechartered, then the BOF will coordinate the LEMONAID requirements with IMAP-EXT. Otherwise, this BOF will consider extensions to IMAP for the purposes of LEMONAID support. Reading List ============ - draft-burger-imap-chanuse-00.txt - draft-burger-um-reqts-00.txt - draft-neystadt-imap-status-counters-00.txt - draft-shapira-snap-03.txt - draft-shveidel-mediasize-00.txt - draft-vaudreuil-futuredelivery-00.txt - draft-vaudreuil-um-issues-00.txt Deep background reading - draft-nerenberg-imap-channel-01.txt - draft-nerenberg-imap-binary-02.txt Milestones ========== Oct 2002 - LEMONAID Requirements Dec 2002 - Notification protocol Mar 2003 - IMAP extensions for VM playback Mar 2003 - IMAP extensions for mobile devices - 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 - 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 Jun 10 13:01:33 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id g5AH1W403888 for um-outgoing; Mon, 10 Jun 2002 13:01:32 -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 g5AH1UB03884 for ; Mon, 10 Jun 2002 13:01:30 -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 g5AH1IU08726 for ; Mon, 10 Jun 2002 13:01:18 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 13:01:18 -0400 Message-ID: From: "Glenn Parsons" To: IETF LEMONAID Subject: RE: [UM] Draft BOF Charter Date: Mon, 10 Jun 2002 13:01:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2109F.9CBFE482" 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_01C2109F.9CBFE482 Content-Type: text/plain; charset="iso-8859-1" For the record, I originally suggested this name ... Profile of INternet mail with Knowledge and License to Enhance MObile Network Access for unifieD mEssaging :-) But I think the latest suggestion is a better name. Glenn. > ---------- > From: Vaudreuil, Greg M (Greg) > Sent: Monday, June 10, 2002 12:32 PM > To: eburger@snowshore.com; IETF LEMONAID > Subject: RE: [UM] Draft BOF Charter > > > I believe a key thrust is the ability for endpoint clients to gain higher > level of network-based messaging service.... so I suggest: > > License to Enhance Messaging Oriented Network Access for Diverse Endpoints > (LEMONADE) > > Greg V. > > > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Monday, June 10, 2002 10:28 AM > To: IETF LEMONAID > Subject: [UM] Draft BOF Charter > > > If we're going to get work done, we need a charter. Here is something to > pick apart. > > The most important issues are... The name and chairs. > > Unless we want a Friday afternoon slot in Yokohama, we need to get this to > Ned shortly. > > Thanks. > > -- > - Eric > > > > > > BOF Name > ======== > License to Enhance Messaging Oriented Network Access for Internet Devices > (LEMONAID) > > > BOF co-chairs > ============= > Looking for volunteers; send me an e-mail! > > > Mailing List > ============ > General Discussion: um@snowshore.com > To Subscribe: majordomo@snowshore.com, In Body: subscribe um > Archive: http://flyingfox.snowshore.com/um_archive/maillist.html > > > Proposed Charter > ================ > Internet Unified Messaging brings together the body of work currently > chartered in VPIM, IFAX, IMAPEXT, and other IETF work groups. The goal is > to provide a single infrastructure, mailbox, and set of interfaces for a > user to get, respond to, and manipulate all of their messages from a > collection of clients with varying capabilities, no matter what the media > or > source. Initial work, in the VPIM and FAX WG for example, focused on the > server and network interactions and has resulted in a rich base of > Internet > Mail standards to support unified messaging. Now that this work is stable > in the industry, and with the proliferation of smaller and often mobile > Internet devices, the issues of client access to Internet Mail need to be > addressed. > > Given the potentially broad scope of "unified messaging", this BOF will > focus on the following work items: > > 1. Enhance message retrieval protocols to satisfy the requirements for > low-latency playback. > > 2. Extend message deposit and retrieval to satisfy the requirements for > low-bit-rate transports and limited-processing devices, such as mobile > endpoints. > > 3. Create appropriate message notification protocols to satisfy the need > of > reporting the status of different message contexts. > > > The BOF will coordinate its efforts with the 3GPP TSG T WG2 SWG3 Messaging > and other appropriate entities, such > as > the W3C Mulitmodal interaction Activity . > > While there is obvious synergy, given the end-of-life of the VPIM and FAX > work groups and the similar membership, the BOF does not expect to > coordinate with those groups. > > If IMAP-EXT gets rechartered, then the BOF will coordinate the LEMONAID > requirements with IMAP-EXT. Otherwise, this BOF will consider extensions > to > IMAP for the purposes of LEMONAID support. > > > > Reading List > ============ > - draft-burger-imap-chanuse-00.txt > - draft-burger-um-reqts-00.txt > - draft-neystadt-imap-status-counters-00.txt > - draft-shapira-snap-03.txt > > - draft-shveidel-mediasize-00.txt > - draft-vaudreuil-futuredelivery-00.txt > > - draft-vaudreuil-um-issues-00.txt > > > Deep background reading > > - draft-nerenberg-imap-channel-01.txt > - draft-nerenberg-imap-binary-02.txt > > > > Milestones > ========== > Oct 2002 - LEMONAID Requirements > > Dec 2002 - Notification protocol > > Mar 2003 - IMAP extensions for VM playback > > Mar 2003 - IMAP extensions for mobile devices > > - > 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 > - > 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 > > ------_=_NextPart_001_01C2109F.9CBFE482 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [UM] Draft BOF Charter

For the record, I = originally suggested this name ...

Profile of INternet = mail with Knowledge and License to Enhance MObile Network Access for = unifieD mEssaging :-)

But I think the = latest suggestion is a better name.

Glenn.

----------
From: Vaudreuil, Greg M (Greg)
Sent: Monday, June 10, 2002 12:32 PM
To: = eburger@snowshore.com; IETF = LEMONAID
Subject: = RE: = [UM] Draft BOF Charter

I believe a key thrust is the ability = for endpoint clients to gain higher
level of network-based messaging = service.... so I suggest:

License to Enhance Messaging Oriented = Network Access for Diverse Endpoints
(LEMONADE)

Greg V.

-----Original Message-----
From: Eric Burger [mailto:eburger@snowshore.com]
Sent: Monday, June 10, 2002 10:28 = AM
To: IETF LEMONAID
Subject: [UM] Draft BOF = Charter

If we're going to get work done, we = need a charter. Here is something to
pick apart.

The most important issues = are... The name and chairs.

Unless we want a Friday afternoon = slot in Yokohama, we need to get this to
Ned shortly.

Thanks.

--
- Eric

BOF Name
=3D=3D=3D=3D=3D=3D=3D=3D
License to Enhance Messaging = Oriented Network Access for Internet Devices
(LEMONAID)

BOF co-chairs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Looking for volunteers; send me an = e-mail!

Mailing List
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
General Discussion: = um@snowshore.com
To Subscribe: = majordomo@snowshore.com, In Body: subscribe um
Archive: http://flyingfox.snowshore.com/um_archive/maillist.htm= l

Proposed Charter
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Internet Unified Messaging brings = together the body of work currently
chartered in VPIM, IFAX, IMAPEXT, = and other IETF work groups. The goal is
to provide a single infrastructure, = mailbox, and set of interfaces for a
user to get, respond to, and = manipulate all of their messages from a
collection of clients with varying = capabilities, no matter what the media or
source. Initial work, in the = VPIM and FAX WG for example, focused on the
server and network interactions and = has resulted in a rich base of Internet
Mail standards to support unified = messaging. Now that this work is stable
in the industry, and with the = proliferation of smaller and often mobile
Internet devices, the issues of = client access to Internet Mail need to be
addressed.

Given the potentially broad scope of = "unified messaging", this BOF will
focus on the following work = items:

1. Enhance message retrieval = protocols to satisfy the requirements for
low-latency playback.

2. Extend message deposit and = retrieval to satisfy the requirements for
low-bit-rate transports and = limited-processing devices, such as mobile
endpoints.

3. Create appropriate message = notification protocols to satisfy the need of
reporting the status of different = message contexts.

The BOF will coordinate its efforts = with the 3GPP TSG T WG2 SWG3 Messaging
<http://www.3gpp.org/TB/T/T2/T2.htm> and other appropriate entities, such = as
the W3C Mulitmodal interaction = Activity <http://www.w3.org/2002/mmi/>.

While there is obvious synergy, given = the end-of-life of the VPIM and FAX
work groups and the similar = membership, the BOF does not expect to
coordinate with those groups.

If IMAP-EXT gets rechartered, then = the BOF will coordinate the LEMONAID
requirements with IMAP-EXT. = Otherwise, this BOF will consider extensions to
IMAP for the purposes of LEMONAID = support.

Reading List
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    - = draft-burger-imap-chanuse-00.txt
    - = draft-burger-um-reqts-00.txt
    - = draft-neystadt-imap-status-counters-00.txt
    - = draft-shapira-snap-03.txt

- = draft-shveidel-mediasize-00.txt
- = draft-vaudreuil-futuredelivery-00.txt

- = draft-vaudreuil-um-issues-00.txt

Deep background reading

- = draft-nerenberg-imap-channel-01.txt
- = draft-nerenberg-imap-binary-02.txt

Milestones
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Oct 2002 - LEMONAID = Requirements

Dec 2002 - Notification = protocol

Mar 2003 - IMAP extensions for VM = playback

Mar 2003 - IMAP extensions for mobile = devices

-
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.htm= l
-
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.htm= l

------_=_NextPart_001_01C2109F.9CBFE482-- - 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 Jun 10 18:00:37 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id g5AM0aP09243 for um-outgoing; Mon, 10 Jun 2002 18:00:36 -0400 (EDT) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g5AM0YB09239 for ; Mon, 10 Jun 2002 18:00:34 -0400 (EDT) Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5AM0QPI013339; Mon, 10 Jun 2002 15:00:26 -0700 (PDT) Received: from DWINGW2K4 (dhcp-128-107-209-152.cisco.com [128.107.209.152]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id AFD18144; Mon, 10 Jun 2002 15:01:32 -0700 (PDT) From: "Dan Wing" To: "Erev, Ari" Cc: , "Shveidel, Vladimir" Subject: [UM] RE: I-D ACTION:draft-shveidel-mediasize-00.txt Date: Mon, 10 Jun 2002 15:00:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C2108F.8D133850" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <7D4344E32B34D511A6500002A560C60202FC11C0@il-tlv-mail4.comverse.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-um@snowshore.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C2108F.8D133850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: I-D ACTION:draft-shveidel-mediasize-00.txt > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-shveidel-mediasize-00.txt > > Hi. > > I'm unable to understand the underlying architecture that caused > you to create this I-D. What architecture of a message store > prevents it from storing, say, 1Mb of audio but allows it to > store 1Mb of plain text? As stated in the 'abstract' section - this I-D is one of the issues and requirements raised by draft-vaudreuil-um-issues-00.txt (see: 3.2 in it). Here is a relevant part from draft-vaudreuil-um-issues-00.txt: It is common in a unified messaging system to offer separate quota's for each of several message contexts to avoid the condition where a flood of email fills the mailbox and prevents the subscriber from receiving voice messages via the telephone. It is necessary to extend the protocols to support the reporting of the "mailbox full" status based on the context of the submitted message. While the preliminary text in draft-vaudreuil-um-issues-00.txt only talked about 'Quota by context' this draft expands a bit so as to (optionally) allow 'quota by media' - where a message of a certain context may hold more than one media type. Thanks. We hoped that a discussion on the list will consider the enhancement and decide whether it is required - or the less flexible 'quota by context' is enough. I don't see how you can get beyond quota by context. That is, I don't see how you could get to quota per media (as mentioned in your I-D in its introduction). > > How is an SMTP client supposed to map the MIME types of a > message to the media types (voice-message, fax-message, > video-message, text-message) that you enumerate in section > 9.1 of your I-D? What of MIME types that the SMTP client > doesn't recognize - how are they to be handled? > This I-D builds on some "work-in-progress' done in VPIM, and specifically on the "Message-Context" I-D (draft-ietf-vpim-hint-08.txt) which is assumed to be used by a "Unified- Messaging-enabled" SMTP client. A non-conforming SMTP client will still work but will not get the benefit of knowning _in advance_ whether the server is ready to accept this message due to its media/context size. This is similar to an SMPT client that does not use the SMTP Size Extension. Thanks. > I found no registration facility for the units used in > examples in your I-D (kb, sec, pages). Unfortunately, the > mechanism to convert or validate one unit to another is > vague. Further, the premise of the entire document is that > an architecture of an SMTP message store doesn't permit > it to store "large" media parts -- yet, the size of a > media part isn't indicated by its duration (seconds) or > length (pages). Rather, only a count of bytes is > meaningful. > As for the registration facitiliy - I think we suggested to consider two options: either to extend the "Message-context" registration with these units, or to extend the 'content-type' registration with these units. As to the mechanism to convert/validate one unit to another - I agree it is somewhat vague. This is because we assumed it to be an implementation issue and not a protocol definition. It directly impacts interoperability, so it's a protocol issue. For example, your I-D says that a server may validate an incoming message's size based on the server's advertised size. If the server said it could receive a 30 second long message, and received a 1Mb audio attachment, I would say the high-fidelity audio attachment (which was 30 seconds in duration) met the requirement, but your implementation might have assumed G.729 compression. For example, in the case of voice-mail systems, they usually support a limited number of formats/codecs and then the conversion is more straight forward. If it's up to the client and server, then please add text to that effect. As written, it's wide open to interpretation and interoperability failures. Certainly, someone implementing or buying a client needs to know that the client's meaning of "seconds" will interoperate with the server's meaning of "seconds" or "megabytes" or "ents" or whatever measure is used. As it's easiest to simply count bytes, I would also suggest just counting bytes. With voice activity detection and fax compression it's difficult to examine the size of an audio file or a TIFF file and guess the duration or number of pages. And, as I believe is stated in Greg's -um-issues- I-D, the length (in bytes) is the problem, not the duration (in time) or length (in pages). I agree that the general case of supporting all sorts of media and encodings is much more complicated and (IMHO) is out of the scope of this I-D. If only the new message-context is supposed to be used, it would be clearer if the I-D just talked about message-context. I think expunging most of the occurrences of the string "media" in the I-D would help. -d ------=_NextPart_000_001F_01C2108F.8D133850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D = ACTION:draft-shveidel-mediasize-00.txt

> > A=20 URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-shveidel-mediasize-00.txt=20
>
> Hi. =
>
> I'm unable to understand = the=20 underlying architecture that caused
> you = to create=20 this I-D. What architecture of a message store
> prevents it from storing, say, 1Mb of audio but allows = it to=20
> store 1Mb of plain text?

As stated in the 'abstract' section - this I-D is = one of the=20 issues and requirements raised by draft-vaudreuil-um-issues-00.txt = (see: 3.2=20 in it).

Here is a relevant part from=20 draft-vaudreuil-um-issues-00.txt:

It is common in a unified messaging system to offer = separate=20 quota's for
each of several message contexts = to avoid=20 the condition where a flood of
email fills = the mailbox=20 and prevents the subscriber from receiving voice
messages via the telephone. It is necessary to extend = the=20 protocols to
support the reporting of the = "mailbox=20 full" status based on the context
of the = submitted=20 message.

While the preliminary text in = draft-vaudreuil-um-issues-00.txt=20 only talked about 'Quota by context' this draft expands a bit so as to = (optionally) allow 'quota by media' - where a message of a certain = context may=20 hold more than one media type.

Thanks.

We hoped that a discussion on the list will consider = the=20 enhancement and decide whether it is required - or the less flexible = 'quota by=20 context' is enough.

I don't see = how you can=20 get beyond quota by context. That is, I don't see how you could = get to=20 quota per media (as mentioned in your I-D in its=20 introduction).

>
> How is an SMTP = client=20 supposed to map the MIME types of a
> = message to=20 the media types (voice-message, fax-message,
>=20 video-message, text-message) that you enumerate in section =
> 9.1 of your I-D? What of MIME types that the SMTP=20 client
> doesn't recognize - how are they = to be=20 handled?
>

This I-D builds on some "work-in-progress' done in = VPIM, and=20 specifically on the "Message-Context" I-D = (draft-ietf-vpim-hint-08.txt) which=20 is assumed to be used by a "Unified- Messaging-enabled" SMTP client. A = non-conforming SMTP client will still work but will not get the = benefit of=20 knowning _in advance_ whether the server is ready to accept this = message due=20 to its media/context size. This is similar to an SMPT client that does = not use=20 the SMTP Size Extension.

Thanks.

> I found no registration facility for the units = used in=20
> examples in your I-D (kb, sec, = pages). =20 Unfortunately, the
> mechanism to convert = or=20 validate one unit to another is
> = vague. =20 Further, the premise of the entire document is that
> an architecture of an SMTP message store doesn't = permit=20
> it to store "large" media parts -- yet, the = size of a=20
> media part isn't indicated by its = duration=20 (seconds) or
> length (pages). = Rather, only a=20 count of bytes is
> meaningful. =
>
As for the registration = facitiliy - I=20 think we suggested to consider two options: either to extend the=20 "Message-context" registration with these units, or to extend the=20 'content-type' registration with these units.

As to the mechanism to convert/validate one unit to = another -=20 I agree it is somewhat vague. This is because we assumed it to be an=20 implementation issue and not a protocol definition.

It directly = impacts=20 interoperability, so it's a protocol issue.

For = example, your I-D=20 says that a server may validate an incoming message's size based on the = server's=20 advertised size. If the server said it could receive a 30 = second long=20 message, and received a 1Mb audio attachment, I would say the = high-fidelity=20 audio attachment (which was 30 seconds in duration) met the requirement, = but=20 your implementation might have assumed G.729 = compression.

For = example, in=20 the case of voice-mail systems, they usually support a limited number = of=20 formats/codecs and then the conversion is more straight forward.

If it's up = to the client=20 and server, then please add text to that effect. As written, it's = wide=20 open to interpretation and interoperability failures. Certainly, = someone=20 implementing or buying a client needs to know that the client's meaning = of=20 "seconds" will interoperate with the server's meaning of "seconds" or=20 "megabytes" or "ents" or whatever measure is used.

As it's = easiest to simply=20 count bytes, I would also suggest just counting bytes. With voice = activity=20 detection and fax compression it's difficult to examine the size of an = audio=20 file or a TIFF file and guess the duration or number of pages. = And, as I=20 believe is stated in Greg's -um-issues- I-D, the length (in bytes) is = the=20 problem, not the duration (in time) or length (in = pages).

I agree that the general case of supporting all = sorts of media=20 and encodings is much more complicated and (IMHO) is out of the scope = of this=20 I-D.

If only the = new=20 message-context is supposed to be used, it would be clearer if the I-D = just=20 talked about message-context. I think expunging most of the = occurrences of=20 the string "media" in the I-D would help.

-d

------=_NextPart_000_001F_01C2108F.8D133850-- - 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 Thu Jun 20 14:39:52 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id g5KIdo313889 for um-outgoing; Thu, 20 Jun 2002 14:39:50 -0400 (EDT) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g5KIdmB13883; Thu, 20 Jun 2002 14:39:48 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5KIchv22918; Thu, 20 Jun 2002 14:38:43 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 14:38:42 -0400 Message-ID: From: "Glenn Parsons" To: "'ned.freed@mrochek.com'" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , agenda@ietf.org Cc: um@snowshore.com, Eric Burger Subject: [UM] Proposed LEMONADE BOF Date: Thu, 20 Jun 2002 14:38:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21889.B2ACA8E2" 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_01C21889.B2ACA8E2 Content-Type: text/plain; charset="iso-8859-1" Ned, As we discussed in FAX and VPIM at the last IETF meeting, we would like to schedule a BOF to discuss what we had called 'Pink Lemonade'. We have put a draft charter together below. Would you please approve this BOF for Yokohama? We suggest that we only need a one hour slot to kick off this BOF. We would like to ensure that it does not clash with the following WGs: VPIM, FAX, IMAPEXT, SIP, SIMPLE, SIPPING, MIDCOM. Further it would be preferable for the BOF to meet after VPIM & FAX. Cheers, Glenn. Proposed LEMONADE Agenda Review of LEMONADE requirements Discussion of proposed work items Discussion of relationships/liaisons with 3GPP, W3C, OMA Call for consensus to form a WG Proposed LEMONADE Charter > BOF Name > ======== > License to Enhance Messaging Oriented Network Access for Diverse Endpoints > (LEMONADE) > > > BOF co-chairs > ============= Eric Burger Glenn Parsons > Mailing List > ============ > General Discussion: um@snowshore.com > To Subscribe: majordomo@snowshore.com, In Body: subscribe um > Archive: http://flyingfox.snowshore.com/um_archive/maillist.html > > > Proposed Charter > ================ > Internet Unified Messaging brings together the body of work currently > chartered in VPIM, IFAX, IMAPEXT, and other IETF work groups. The goal is > to provide a single infrastructure, mailbox, and set of interfaces for a > user to get, respond to, and manipulate all of their messages from a > collection of clients with varying capabilities, no matter what the media > or > source. Initial work, in the VPIM and FAX WG for example, focused on the > server and network interactions and has resulted in a rich base of > Internet > Mail standards to support unified messaging. Now that this work is stable > in the industry, and with the proliferation of smaller and often mobile > Internet devices, the issues of client access to Internet Mail need to be > addressed. > > Given the potentially broad scope of "unified messaging", this BOF will > focus on the following work items: > > 1. Enhance message retrieval protocols to satisfy the requirements for > low-latency playback. > > 2. Extend message deposit and retrieval to satisfy the requirements for > low-bit-rate transports and limited-processing devices, such as mobile > endpoints. > > 3. Create appropriate message notification protocols to satisfy the need > of > reporting the status of different message contexts. > > > The BOF will coordinate its efforts with the 3GPP TSG T WG2 SWG3 Messaging > and other appropriate entities, such > as > the W3C Mulitmodal interaction Activity and > the Open Mobile Alliance . > While there is obvious synergy, given the end-of-life of the VPIM and FAX > work groups and the similar membership, the BOF does not expect to > coordinate with those groups. > > If IMAP-EXT gets rechartered, then the BOF will coordinate the LEMONADE > requirements with IMAP-EXT. Otherwise, this BOF will consider extensions > to > IMAP for the purposes of LEMONADE support. > > > > Reading List > ============ > - draft-burger-imap-chanuse-00.txt > - draft-burger-um-reqts-00.txt > - draft-neystadt-imap-status-counters-00.txt > - draft-shapira-snap-03.txt > > - draft-shveidel-mediasize-00.txt > - draft-vaudreuil-futuredelivery-00.txt > > - draft-vaudreuil-um-issues-00.txt > > > Deep background reading > > - draft-nerenberg-imap-channel-01.txt > - draft-nerenberg-imap-binary-02.txt > > > > Milestones > ========== > Oct 2002 - LEMONADE Requirements > > Dec 2002 - Notification protocol > > Mar 2003 - IMAP extensions for VM playback > > Mar 2003 - IMAP extensions for mobile devices > ------_=_NextPart_001_01C21889.B2ACA8E2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Proposed LEMONADE BOF

Ned,

As we discussed in = FAX and VPIM at the last IETF meeting, we would like to schedule a BOF = to discuss what we had called 'Pink Lemonade'. We have put a = draft charter together below.

Would you please = approve this BOF for Yokohama?

We suggest that we = only need a one hour slot to kick off this BOF. We would like to = ensure that it does not clash with the following WGs: VPIM, FAX, = IMAPEXT, SIP, SIMPLE, SIPPING, MIDCOM. Further it would be = preferable for the BOF to meet after VPIM & FAX.

Cheers,
Glenn.

Proposed LEMONADE = Agenda

Review of LEMONADE = requirements
Discussion of = proposed work items
Discussion of = relationships/liaisons with 3GPP, W3C, OMA
Call for consensus = to form a WG

Proposed LEMONADE = Charter

BOF Name
=3D=3D=3D=3D=3D=3D=3D=3D
License to Enhance Messaging = Oriented Network Access for Diverse Endpoints
(LEMONADE)

BOF co-chairs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Eric Burger <eburger@snowshore.com>
Glenn Parsons = <gparsons@nortelnetworks.com>

Given the potentially broad scope of = "unified messaging", this BOF will
focus on the following work = items:

1. Enhance message retrieval = protocols to satisfy the requirements for
low-latency playback.

2. Extend message deposit and = retrieval to satisfy the requirements for
low-bit-rate transports and = limited-processing devices, such as mobile
endpoints.

3. Create appropriate message = notification protocols to satisfy the need of
reporting the status of different = message contexts.

While there is obvious synergy, given = the end-of-life of the VPIM and FAX
work groups and the similar = membership, the BOF does not expect to
coordinate with those groups.

If IMAP-EXT gets rechartered, then = the BOF will coordinate the LEMONADE
requirements with IMAP-EXT. = Otherwise, this BOF will consider extensions to
IMAP for the purposes of LEMONADE = support.

- = draft-shveidel-mediasize-00.txt
- = draft-vaudreuil-futuredelivery-00.txt

- = draft-vaudreuil-um-issues-00.txt

Deep background reading

- = draft-nerenberg-imap-channel-01.txt
- = draft-nerenberg-imap-binary-02.txt

Milestones
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Oct 2002 - LEMONADE = Requirements

Dec 2002 - Notification = protocol

Mar 2003 - IMAP extensions for VM = playback

Mar 2003 - IMAP extensions for mobile = devices

------_=_NextPart_001_01C21889.B2ACA8E2-- - 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 Sun Jun 23 02:32:00 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id g5N6VwC24405 for um-outgoing; Sun, 23 Jun 2002 02:31:58 -0400 (EDT) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from il-tlv-smtpout2.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g5N6VjB24399; Sun, 23 Jun 2002 02:31:46 -0400 (EDT) Received: from il-tlv-mbdg1.icomverse.com (il-tlv-mbdg1.comverse.com [10.116.200.32]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id g5N6BE712358; Sun, 23 Jun 2002 09:11:15 +0300 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id ; Sun, 23 Jun 2002 09:31:03 +0300 Message-ID: <7D4344E32B34D511A6500002A560C60202FC1268@il-tlv-mail4.comverse.com> From: "Erev, Ari" To: "'Glenn Parsons'" , "'ned.freed@mrochek.com'" Cc: um@snowshore.com, Eric Burger , Patrik F?ltstr?m , agenda@ietf.org Subject: RE: [UM] Proposed LEMONADE BOF Date: Sun, 23 Jun 2002 09:31:02 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21A7F.8B97C686" 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_01C21A7F.8B97C686 Content-Type: text/plain; charset="iso-8859-1" Glenn and Ned, I support Glenn's request. In addition, to be on the safe side, I suggest allocating more than one hour. There were some comments on some of the requirements as well as some initial work items which may not be addressed in one hour. Regards, Ari Erev -----Original Message----- From: Glenn Parsons [mailto:gparsons@nortelnetworks.com] Sent: Thursday, June 20, 2002 9:39 PM To: 'ned.freed@mrochek.com'; Patrik F?ltstr?m; agenda@ietf.org Cc: um@snowshore.com; Eric Burger Subject: [UM] Proposed LEMONADE BOF Ned, As we discussed in FAX and VPIM at the last IETF meeting, we would like to schedule a BOF to discuss what we had called 'Pink Lemonade'. We have put a draft charter together below. Would you please approve this BOF for Yokohama? We suggest that we only need a one hour slot to kick off this BOF. We would like to ensure that it does not clash with the following WGs: VPIM, FAX, IMAPEXT, SIP, SIMPLE, SIPPING, MIDCOM. Further it would be preferable for the BOF to meet after VPIM & FAX. Cheers, Glenn. Proposed LEMONADE Agenda Review of LEMONADE requirements Discussion of proposed work items Discussion of relationships/liaisons with 3GPP, W3C, OMA Call for consensus to form a WG Proposed LEMONADE Charter BOF Name ======== License to Enhance Messaging Oriented Network Access for Diverse Endpoints (LEMONADE) BOF co-chairs ============= Eric Burger Glenn Parsons Mailing List ============ General Discussion: um@snowshore.com To Subscribe: majordomo@snowshore.com, In Body: subscribe um Archive: http://flyingfox.snowshore.com/um_archive/maillist.html Proposed Charter ================ Internet Unified Messaging brings together the body of work currently chartered in VPIM, IFAX, IMAPEXT, and other IETF work groups. The goal is to provide a single infrastructure, mailbox, and set of interfaces for a user to get, respond to, and manipulate all of their messages from a collection of clients with varying capabilities, no matter what the media or source. Initial work, in the VPIM and FAX WG for example, focused on the server and network interactions and has resulted in a rich base of Internet Mail standards to support unified messaging. Now that this work is stable in the industry, and with the proliferation of smaller and often mobile Internet devices, the issues of client access to Internet Mail need to be addressed. Given the potentially broad scope of "unified messaging", this BOF will focus on the following work items: 1. Enhance message retrieval protocols to satisfy the requirements for low-latency playback. 2. Extend message deposit and retrieval to satisfy the requirements for low-bit-rate transports and limited-processing devices, such as mobile endpoints. 3. Create appropriate message notification protocols to satisfy the need of reporting the status of different message contexts. The BOF will coordinate its efforts with the 3GPP TSG T WG2 SWG3 Messaging < http://www.3gpp.org/TB/T/T2/T2.htm > and other appropriate entities, such as the W3C Mulitmodal interaction Activity < http://www.w3.org/2002/mmi/ > and the Open Mobile Alliance < http://www.openmobilealliance.org/ >. While there is obvious synergy, given the end-of-life of the VPIM and FAX work groups and the similar membership, the BOF does not expect to coordinate with those groups. If IMAP-EXT gets rechartered, then the BOF will coordinate the LEMONADE requirements with IMAP-EXT. Otherwise, this BOF will consider extensions to IMAP for the purposes of LEMONADE support. Reading List ============ - draft-burger-imap-chanuse-00.txt - draft-burger-um-reqts-00.txt - draft-neystadt-imap-status-counters-00.txt - draft-shapira-snap-03.txt - draft-shveidel-mediasize-00.txt - draft-vaudreuil-futuredelivery-00.txt - draft-vaudreuil-um-issues-00.txt Deep background reading - draft-nerenberg-imap-channel-01.txt - draft-nerenberg-imap-binary-02.txt Milestones ========== Oct 2002 - LEMONADE Requirements Dec 2002 - Notification protocol Mar 2003 - IMAP extensions for VM playback Mar 2003 - IMAP extensions for mobile devices ------_=_NextPart_001_01C21A7F.8B97C686 Content-Type: text/html; charset="iso-8859-1" Proposed LEMONADE BOF

Glenn and Ned,

I support Glenn's request.

In addition, to be on the safe side, I suggest allocating more than one hour.

There were some comments on some of the requirements as well as some initial work items which may not be addressed in one hour.

Regards,

Ari Erev

-----Original Message-----
From: Glenn Parsons [mailto:gparsons@nortelnetworks.com]
Sent: Thursday, June 20, 2002 9:39 PM
To: 'ned.freed@mrochek.com'; Patrik F?ltstr?m; agenda@ietf.org
Cc: um@snowshore.com; Eric Burger
Subject: [UM] Proposed LEMONADE BOF

Ned,

As we discussed in FAX and VPIM at the last IETF meeting, we would like to schedule a BOF to discuss what we had called 'Pink Lemonade'. We have put a draft charter together below.

Would you please approve this BOF for Yokohama?

We suggest that we only need a one hour slot to kick off this BOF. We would like to ensure that it does not clash with the following WGs: VPIM, FAX, IMAPEXT, SIP, SIMPLE, SIPPING, MIDCOM. Further it would be preferable for the BOF to meet after VPIM & FAX.

Cheers,
Glenn.

Proposed LEMONADE Agenda

Review of LEMONADE requirements
Discussion of proposed work items
Discussion of relationships/liaisons with 3GPP, W3C, OMA
Call for consensus to form a WG

Proposed LEMONADE Charter

BOF Name
========
License to Enhance Messaging Oriented Network Access for Diverse Endpoints
(LEMONADE)

BOF co-chairs
=============
Eric Burger <eburger@snowshore.com>
Glenn Parsons <gparsons@nortelnetworks.com>

Mailing List
============
General Discussion: um@snowshore.com
To Subscribe: majordomo@snowshore.com, In Body: subscribe um
Archive: http://flyingfox.snowshore.com/um_archive/maillist.html

Proposed Charter
================
Internet Unified Messaging brings together the body of work currently
chartered in VPIM, IFAX, IMAPEXT, and other IETF work groups. The goal is
to provide a single infrastructure, mailbox, and set of interfaces for a
user to get, respond to, and manipulate all of their messages from a
collection of clients with varying capabilities, no matter what the media or
source. Initial work, in the VPIM and FAX WG for example, focused on the
server and network interactions and has resulted in a rich base of Internet
Mail standards to support unified messaging. Now that this work is stable
in the industry, and with the proliferation of smaller and often mobile
Internet devices, the issues of client access to Internet Mail need to be
addressed.

Given the potentially broad scope of "unified messaging", this BOF will
focus on the following work items:

1. Enhance message retrieval protocols to satisfy the requirements for
low-latency playback.

2. Extend message deposit and retrieval to satisfy the requirements for
low-bit-rate transports and limited-processing devices, such as mobile
endpoints.

3. Create appropriate message notification protocols to satisfy the need of
reporting the status of different message contexts.

The BOF will coordinate its efforts with the 3GPP TSG T WG2 SWG3 Messaging
<http://www.3gpp.org/TB/T/T2/T2.htm> and other appropriate entities, such as
the W3C Mulitmodal interaction Activity <http://www.w3.org/2002/mmi/> and the
Open Mobile Alliance <http://www.openmobilealliance.org/>.

While there is obvious synergy, given the end-of-life of the VPIM and FAX
work groups and the similar membership, the BOF does not expect to
coordinate with those groups.

If IMAP-EXT gets rechartered, then the BOF will coordinate the LEMONADE
requirements with IMAP-EXT. Otherwise, this BOF will consider extensions to
IMAP for the purposes of LEMONADE support.

Reading List
============
    - draft-burger-imap-chanuse-00.txt
    - draft-burger-um-reqts-00.txt
    - draft-neystadt-imap-status-counters-00.txt
    - draft-shapira-snap-03.txt

    - draft-shveidel-mediasize-00.txt
    - draft-vaudreuil-futuredelivery-00.txt

    - draft-vaudreuil-um-issues-00.txt

Deep background reading

    - draft-nerenberg-imap-channel-01.txt
    - draft-nerenberg-imap-binary-02.txt

Milestones
==========
Oct 2002 - LEMONADE Requirements

Dec 2002 - Notification protocol

Mar 2003 - IMAP extensions for VM playback

Mar 2003 - IMAP extensions for mobile devices

------_=_NextPart_001_01C21A7F.8B97C686-- - 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 Jun 26 11:10:46 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id g5QFAjT25801 for um-outgoing; Wed, 26 Jun 2002 11:10:45 -0400 (EDT) X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g5QF4WB25683 for ; Wed, 26 Jun 2002 11:04:32 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5QF3hg15528; Wed, 26 Jun 2002 11:03:44 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 11:03:42 -0400 Message-ID: From: "Glenn Parsons" To: vpim@lists.neystadt.org Cc: ietf-fax@imc.org, "'um@snowshore.com'" Subject: [UM] Draft Agenda for VPIM Date: Wed, 26 Jun 2002 11:03:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21D21.40C8A414" 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_01C21D21.40C8A414 Content-Type: text/plain; charset="iso-8859-1" Folks, As you may recall from IETF 53, we have agreed to meet jointly at IETF 54 and likely future IETF meetings until we wrap up. The slot we have been assigned is: 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: VPIMv2 - status of publication (MDN & DSN dependency) VPIM Directory - schema status - ENUM status IVM - status of last calls - review of IVM base spec Addenda - status of last calls - IMAP channel, Client Behaviour, Caller-ID, SNAP,... We can discuss which of the Addenda items we think should roll into LEMONADE, if any... BTW, LEMONADE meets on Thursday: THURSDAY, July 18, 2002 1530-1730 Afternoon Sessions II APP lemonade License to Enhance Messaging Oriented Network Access for Diverse Endpoints BOF Let me know if there is anything else you think we should cover or would like to discuss at the meeting. I will send out a more detailed agenda (with draft names) closer to the meeting. Cheers, Glenn. ------_=_NextPart_001_01C21D21.40C8A414 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Draft Agenda for VPIM

Folks,

As you may recall = from IETF 53, we have agreed to meet jointly at IETF 54 and likely = future IETF meetings until we wrap up. The slot we have been = assigned is:

TUESDAY, July 16, 2002
0900-1130 Morning Sessions
APP = fax&vpim Internet Fax WG & Voice Profile for Internet = Mail WG=A0

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:

=A0=A0=A0=A0=A0=A0=A0 VPIMv2=20
=A0 - status of = publication (MDN & DSN dependency)

=A0=A0=A0=A0=A0=A0=A0 VPIM Directory=20
=A0 - schema status=20
=A0 - ENUM status

=A0=A0=A0=A0=A0=A0=A0 IVM=20
=A0 - status of last = calls
=A0 - review of IVM base spec=20

=A0=A0=A0=A0=A0=A0=A0 Addenda=20
=A0 - status of last calls=20
=A0 - IMAP channel, Client = Behaviour, Caller-ID, SNAP,... =

We can discuss which of the = Addenda items we think should roll into LEMONADE, if any... = BTW, LEMONADE meets on Thursday:

THURSDAY, July 18, 2002
1530-1730 Afternoon Sessions = II
APP = lemonade License to Enhance Messaging Oriented Network Access for = Diverse Endpoints BOF

Let me know if there is = anything else you think we should cover or would like to discuss at the = meeting.=A0 I will send out a more detailed agenda (with draft names) = closer to the meeting.

Cheers,
Glenn.

------_=_NextPart_001_01C21D21.40C8A414-- - 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 Jun 26 18:55:59 2002 Received: (from majordomo@localhost) by flyingfox.snowshore.com (8.11.2/8.11.2) id g5QMtxl04186 for um-outgoing; Wed, 26 Jun 2002 18:55: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 g5QMtuB04182 for ; Wed, 26 Jun 2002 18:55:57 -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 g5QMtcr31225; Thu, 27 Jun 2002 07:55:38 +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 ACY67360; Thu, 27 Jun 2002 07:55:37 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id HAA17130; Thu, 27 Jun 2002 07:51:24 +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 In-Reply-To: References: 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: <20020627075755F.tamura@toda.ricoh.co.jp> Date: Thu, 27 Jun 2002 07:57:55 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 27 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. 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. 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