From owner-ietf-fax@imc.org Fri Feb 4 18:05:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12443 for ; Fri, 4 Feb 2000 18:05:45 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA26309 for ietf-fax-bks; Fri, 4 Feb 2000 14:23:17 -0800 (PST) Received: from spdmraac.compuserve.com (ds-img-rel-3.compuserve.com [149.174.206.154]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA26305 for ; Fri, 4 Feb 2000 14:23:15 -0800 (PST) Received: (from mailgate@localhost) by spdmraac.compuserve.com (8.9.3/8.9.3/SUN-REL-1.2) id RAA00318 for ietf-fax@imc.org; Fri, 4 Feb 2000 17:25:17 -0500 (EST) Received: from jraff.brooktrout.com (fra-pci-lah-vty35.as.wcom.net [212.211.68.35]) by spdmraac.compuserve.com (8.9.3/8.9.3/SUN-REL-1.2) with SMTP id RAA00288; Fri, 4 Feb 2000 17:25:09 -0500 (EST) Message-Id: Message-Id: X-Sender: jrafferty@humancomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 04 Feb 2000 23:22:38 +0100 To: Ietf-Fax From: James Rafferty Subject: [Fax] Draft Communication to ITU SG8 Cc: Keith Moore , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , VP Standards ISOC, Ned Freed Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA26306 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit To all - At our last IETF meeting, we agreed to send a communication to the ITU-T Study Group 8 giving an update on our WG activities. I've been meaning to do this, but was delayed. So, here is a draft of it. Please review and I'll incorporate comments as needed. I will plan to send it out to Herman Silbiger (SG8/Q4 Rapporteur) late this weekend. Thanks, James Rafferty Chair, IETF Internet Fax Working Group Draft Follows: To: Herman Silbiger, Rapporteur, Question 4, ITU-T Study Group 8 From: James Rafferty, Chair, IETF Internet Fax Working Group cc: Wilhelm Staudinger, Scott Bradner, Keith Moore, Patrik Falstrom Subject: Communication on Current IETF Internet Fax Activities - For Information The IETF Internet Fax working group is nearing the completion of its initial phase of activities per the charter of the working group. The purpose of this memo is to provide a status update about current activities and to outline potential future directions for the next phase of work. Particular attention is given to the status of documents which are in process which will have some impact on existing RFCs whjch are referenced directly or indirectly within the T.37 recommendation. Status of Current Activities The working group is in the process of completing the activities specified in the original charter. In line with this, there is a collection of documents which has gone through working group Last Call. These documents are drafts which are proposed for submission to the IESG in the near future at the Draft Standard level. The resulting RFCs would ultimately replace the current RFCs 2301, 2302, 2303, 2304 and 2305. The changes proposed from the existing RFCs are not considered to be technical in nature. There are some small refinements included in the documents which have resulted based on feedback from implementors, primarily to clarify the meaning of some portions of the text. At this time, there are still some additional interworking tests that need to be conducted for RFC 2303-2304 related to the support of GSTN addresses in email addresses. In addition, there are some references contained within RFC 2305 which are at the proposed standard level. In order to progress RFC 2305 to the draft standard level, all of its normative references also need to be at the draft level. The working group has submitted two additional documents to the Internet Engineering Steering Group for Last Call. The working group proposes that the following draft document be approved as a Proposed Standard RFC which is intended to replace RFC 2531: - draft-ietf-fax-feature-schema-v2-01.txt - Content Feature Schema for Internet Fax (V2) The working group also proposes that the following new document be approved as an informational RFC: - draft-ietf-fax-T30-mapping-03.txt - Internet fax T.30 Feature Mapping Document Revisions Related to T.37 There has been a new RFC 2738 approved which provides a correction to RFC 2533. RFC 2533 is one of the embedded references within RFCs 2530, 2531 and 2532 which are referenced within T.37 amendment 1. The new RFC provides correction for a single small syntax error and fixes and editorial point. As noted above, there is a proposal to replace RFC 2531 with an updated version which provides some small technical changes. This document has not yet been appoved by the IESG. There is also pending action on the documents which define the Simple Mode for Internet Fax (RFC 2301-2305). These documents are in a working group last call. The intention is to submitted the completed documents and documentation of the required interworking reports to the IESG for consideration as Draft Standards. Draft Standard is the next level of standardization after Proposed Standard. No technical changes are anticipated in these documents. The RFCs 2301, 2303, 2304 and 2305 are referenced in T.37. Plans for Future Work There has been some initial discussion inthe working group about new phases of work. In particular, there has been further review concerning the best ways to more fully realize the "Full Mode" of Internet fax. There are some initial Internet Drafts on how to accomplish this. Since this work is beyond the scope of the original chartered effort, it has been proposed that additional work be done under a re-chartered Internet Fax working group or in a Fax extensions working group. The working group reviewed these ideas at its last meeting in November 1999 and a draft charter is under development. It has been noted that there is an ongoing need to maintain communications with the Questions in the ITU which are studying Internet fax and to maintain synchronization between standards documents as new standard facsimile features are introduced. The following draft charter is under review. It has not yet been finalized. Comments are invited. Draft Charter for Future Work Internet Fax Extensions (faxext) -------------------------------- Chair(s): Applications Area Director(s): Keith Moore Patrik F„ltstr”m Area Advisor Mailing lists: General Discussion:ietf-fax@imc.org To Subscribe: ietf-fax-request@imc.org In Body: In Body: subscribe Archive: http://www.imc.org/ietf-fax/ Description of Working Group: Previous IETF efforts developed specifications for simple and extended Internet mail-based facsimile service profiles, tailored to interwork with the world of T.30 facsimile. This extension effort will produce a final increment of specification for supporting a "full" equivalence of T.30 service over Internet mail. Technical work for this effort includes timely delivery, document privacy, and integrated specification of Full-mode Facsimile Profile of Internet Mail (FFPIM). Differential routing between classic Internet mail and timely deliveries will be considered, as will universal messaging issues. For interconnecting fax services over the dial-up telephone network and carriage of facsimile message data over the Internet, two types of interface systems are required: o Internet/Dial-up Fax gateway, moving data from the Internet to classic or Internet-aware dial-up fax products and services o Dial-up/Internet Fax gateway, moving data from classic or Internet-aware dial-up fax products and services to the Internet The working group will also consider the requirements for gatewaying Internet Mail (Simple, Extended modes and FFPIM) with T.30 Facsimile. The working group will specifically take note of quality of service issues and might decide to produce an Implementer's Guide, especially to deal with the question of routing for timely delivery. T.30 facsimile carries expectations of message privacy, so that FFPIM must specify a basic facility via the Internet. Although T.30 does not provide document authentication, users frequently believe that it does. Consequently the Faxext working group will also seek specification of a basic authentication facility over the Internet. Additional areas of discussion will be: Annotated fax messages and universal messaging issues as they relate to FFPIM, as well as schema and TIFF extensions required to support the new JBIG-2 (T.88) compression method. The working group will continue the excellent pattern of coordinating activities with other facsimile-related standards bodies, and with using work from related IETF efforts. Goals and Milestones: Mar 2000 Initial drafts for timely delivery and FFPIM Jun 2000 Revised drafts Mar 2000 Working Group chartered Jul 2000 Routing considerations draft Jul 2000 Initial draft of gateway requirements Sep 2000 Initial drafts of schema and TIFF-fx extensions for JBIG-2 Nov 2000 Final draft for timely delivery. Nov 2000 Final draft of Routing Considerations Nov 2000 Final draft of FFPIM Mar 2001 Final draft of gateway requirements Apr 2001 Final drafts of schema and TIFF-fx extensions for JBIG-2 --------------------------------------------------------- From owner-ietf-fax@imc.org Sun Feb 6 18:02:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13475 for ; Sun, 6 Feb 2000 18:02:39 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA01660 for ietf-fax-bks; Sun, 6 Feb 2000 14:28:46 -0800 (PST) Received: from ties.itu.ch (root@ties.itu.ch [156.106.192.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01656 for ; Sun, 6 Feb 2000 14:28:44 -0800 (PST) Received: from jraff.brooktrout.com (usr-004.itu.ch [156.106.194.4]) by ties.itu.ch (8.9.3/8.9.3) with SMTP id XAA30517; Sun, 6 Feb 2000 23:31:24 +0100 (MET) Message-Id: <200002062231.XAA30517@ties.itu.ch> X-Sender: jrafferty@humancomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sun, 06 Feb 2000 23:27:28 +0100 To: Ietf-Fax From: James Rafferty Subject: Re: [Fax] Draft Communication to ITU SG8 Cc: Keith Moore , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , VP Standards ISOC, Ned Freed In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I did not receive any corrections to the draft ITU communication sent out Friday, so I am sending it out. I have made a couple of small changes to the cc list to make sure it gets to all of our ADs and the relevant SG8 people. It needs to be sent out right away in order for SG8 Q4 to have time to read it during their meeting this week and send comments back to us if applicable. James At 11:22 PM 2/4/00 +0100, James Rafferty wrote: >To all - > >At our last IETF meeting, we agreed to send a communication to the ITU-T >Study Group 8 >giving an update on our WG activities. > >I've been meaning to do this, but was delayed. So, here is a draft of it. > Please review and >I'll incorporate comments as needed. I will plan to send it out to Herman >Silbiger (SG8/Q4 Rapporteur) >late this weekend. > >Thanks, > >James Rafferty >Chair, IETF Internet Fax Working Group > From owner-ietf-fax@imc.org Sun Feb 6 18:02:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13486 for ; Sun, 6 Feb 2000 18:02:48 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA01666 for ietf-fax-bks; Sun, 6 Feb 2000 14:29:04 -0800 (PST) Received: from ties.itu.ch (root@ties.itu.ch [156.106.192.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01662 for ; Sun, 6 Feb 2000 14:29:03 -0800 (PST) Received: from jraff.brooktrout.com (usr-004.itu.ch [156.106.194.4]) by ties.itu.ch (8.9.3/8.9.3) with SMTP id XAA30802; Sun, 6 Feb 2000 23:31:20 +0100 (MET) Message-Id: <200002062231.XAA30802@ties.itu.ch> X-Sender: jrafferty@humancomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sun, 06 Feb 2000 23:28:35 +0100 To: "Herman R. Silbiger" From: James Rafferty Subject: [Fax] Communication to ITU SG8 Cc: Keith Moore , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , VP Standards ISOC, Ned Freed , Ietf-Fax , Wilhelm Staudinger , Frank Cohen Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA01663 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit To: Herman Silbiger, Rapporteur, Question 4, ITU-T Study Group 8 From: James Rafferty, Chair, IETF Internet Fax Working Group cc: Wilhelm Staudinger, Scott Bradner, Keith Moore, Patrik Falstrom, Ned Freed, Frank Cohen Subject: Communication on Current IETF Internet Fax Activities - For Information The IETF Internet Fax working group is nearing the completion of its initial phase of activities per the charter of the working group. The purpose of this memo is to provide a status update about current activities and to outline potential future directions for the next phase of work. Particular attention is given to the status of documents which are in process which will have some impact on existing RFCs whjch are referenced directly or indirectly within the T.37 recommendation. Status of Current Activities The working group is in the process of completing the activities specified in the original charter. In line with this, there is a collection of documents which has gone through working group Last Call. These documents are drafts which are proposed for submission to the IESG in the near future at the Draft Standard level. The resulting RFCs would ultimately replace the current RFCs 2301, 2302, 2303, 2304 and 2305. The changes proposed from the existing RFCs are not considered to be technical in nature. There are some small refinements included in the documents which have resulted based on feedback from implementors, primarily to clarify the meaning of some portions of the text. At this time, there are still some additional interworking tests that need to be conducted for RFC 2303-2304 related to the support of GSTN addresses in email addresses. In addition, there are some references contained within RFC 2305 which are at the proposed standard level. In order to progress RFC 2305 to the draft standard level, all of its normative references also need to be at the draft level. The working group has submitted two additional documents to the Internet Engineering Steering Group for Last Call. The working group proposes that the following draft document be approved as a Proposed Standard RFC which is intended to replace RFC 2531: - draft-ietf-fax-feature-schema-v2-01.txt - Content Feature Schema for Internet Fax (V2) The working group also proposes that the following new document be approved as an informational RFC: - draft-ietf-fax-T30-mapping-03.txt - Internet fax T.30 Feature Mapping Document Revisions Related to T.37 There has been a new RFC 2738 approved which provides a correction to RFC 2533. RFC 2533 is one of the embedded references within RFCs 2530, 2531 and 2532 which are referenced within T.37 amendment 1. The new RFC provides correction for a single small syntax error and fixes and editorial point. As noted above, there is a proposal to replace RFC 2531 with an updated version which provides some small technical changes. This document has not yet been appoved by the IESG. There is also pending action on the documents which define the Simple Mode for Internet Fax (RFC 2301-2305). These documents are in a working group last call. The intention is to submitted the completed documents and documentation of the required interworking reports to the IESG for consideration as Draft Standards. Draft Standard is the next level of standardization after Proposed Standard. No technical changes are anticipated in these documents. The RFCs 2301, 2303, 2304 and 2305 are referenced in T.37. Plans for Future Work There has been some initial discussion inthe working group about new phases of work. In particular, there has been further review concerning the best ways to more fully realize the "Full Mode" of Internet fax. There are some initial Internet Drafts on how to accomplish this. Since this work is beyond the scope of the original chartered effort, it has been proposed that additional work be done under a re-chartered Internet Fax working group or in a Fax extensions working group. The working group reviewed these ideas at its last meeting in November 1999 and a draft charter is under development. It has been noted that there is an ongoing need to maintain communications with the Questions in the ITU which are studying Internet fax and to maintain synchronization between standards documents as new standard facsimile features are introduced. The following draft charter is under review. It has not yet been finalized. Comments are invited. Draft Charter for Future Work Internet Fax Extensions (faxext) -------------------------------- Chair(s): Applications Area Director(s): Keith Moore Patrik F„ltstr”m Area Advisor Mailing lists: General Discussion:ietf-fax@imc.org To Subscribe: ietf-fax-request@imc.org In Body: In Body: subscribe Archive: http://www.imc.org/ietf-fax/ Description of Working Group: Previous IETF efforts developed specifications for simple and extended Internet mail-based facsimile service profiles, tailored to interwork with the world of T.30 facsimile. This extension effort will produce a final increment of specification for supporting a "full" equivalence of T.30 service over Internet mail. Technical work for this effort includes timely delivery, document privacy, and integrated specification of Full-mode Facsimile Profile of Internet Mail (FFPIM). Differential routing between classic Internet mail and timely deliveries will be considered, as will universal messaging issues. For interconnecting fax services over the dial-up telephone network and carriage of facsimile message data over the Internet, two types of interface systems are required: o Internet/Dial-up Fax gateway, moving data from the Internet to classic or Internet-aware dial-up fax products and services o Dial-up/Internet Fax gateway, moving data from classic or Internet-aware dial-up fax products and services to the Internet The working group will also consider the requirements for gatewaying Internet Mail (Simple, Extended modes and FFPIM) with T.30 Facsimile. The working group will specifically take note of quality of service issues and might decide to produce an Implementer's Guide, especially to deal with the question of routing for timely delivery. T.30 facsimile carries expectations of message privacy, so that FFPIM must specify a basic facility via the Internet. Although T.30 does not provide document authentication, users frequently believe that it does. Consequently the Faxext working group will also seek specification of a basic authentication facility over the Internet. Additional areas of discussion will be: Annotated fax messages and universal messaging issues as they relate to FFPIM, as well as schema and TIFF extensions required to support the new JBIG-2 (T.88) compression method. The working group will continue the excellent pattern of coordinating activities with other facsimile-related standards bodies, and with using work from related IETF efforts. Goals and Milestones: Mar 2000 Initial drafts for timely delivery and FFPIM Jun 2000 Revised drafts Mar 2000 Working Group chartered Jul 2000 Routing considerations draft Jul 2000 Initial draft of gateway requirements Sep 2000 Initial drafts of schema and TIFF-fx extensions for JBIG-2 Nov 2000 Final draft for timely delivery. Nov 2000 Final draft of Routing Considerations Nov 2000 Final draft of FFPIM Mar 2001 Final draft of gateway requirements Apr 2001 Final drafts of schema and TIFF-fx extensions for JBIG-2 --------------------------------------------------------- From owner-ietf-fax@imc.org Mon Feb 7 11:50:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14978 for ; Mon, 7 Feb 2000 11:50:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA28954 for ietf-fax-bks; Mon, 7 Feb 2000 08:14:56 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28950 for ; Mon, 7 Feb 2000 08:14:55 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA04403 for ; Mon, 7 Feb 2000 08:13:45 -0800 (PST) Received: from netscape.com ([208.12.63.45]) by dredd.mcom.com (Netscape Messaging Server 4.1 Aug 9 1999 18:28:31) with ESMTP id FPKIKN00.SU2; Mon, 7 Feb 2000 08:17:11 -0800 Message-ID: <389EF04C.CFA2C450@netscape.com> Date: Mon, 07 Feb 2000 08:18:20 -0800 From: dboreham@netscape.com (David Boreham) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Glenn Parsons CC: IETF VPIM List , ietf-fax@imc.org Subject: Re: [VPIM] Analogy to Content-Duration for Faxes References: <456E6DB7180ED3118A670000F8BDCA2901C52BFE@zcard00p.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Glenn Parsons wrote: > At one point we had proposed a 'Content-Length' header specifically > for fax page count. I cannot remember if it was ever included in an > RFC or not. > > In practice, we have found it more practical to put thie information > in the Subject field. Then the user will see the info in their GUI. Ugh. I've always hated that subject overloading (voice mail systems do it too). It would be better I think to define header properties which are renderable in the GUI and break bread with the e-mail client developers (there's only about three of them now) to get the fields rendered. From owner-ietf-fax@imc.org Mon Feb 7 11:52:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15039 for ; Mon, 7 Feb 2000 11:52:25 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA28715 for ietf-fax-bks; Mon, 7 Feb 2000 08:05:47 -0800 (PST) Received: from smtprtp.ntcom.nortel.net (smtprtp.ntcom.nortel.net [137.118.22.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28711 for ; Mon, 7 Feb 2000 08:05:46 -0800 (PST) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp.ntcom.nortel.net; Mon, 7 Feb 2000 11:07:27 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id <1NWN5M6S>; Mon, 7 Feb 2000 11:07:28 -0500 Message-ID: <456E6DB7180ED3118A670000F8BDCA2901C52BFE@zcard00p.ca.nortel.com> From: "Glenn Parsons" To: IETF VPIM List Cc: ietf-fax@imc.org Subject: RE: [VPIM] Analogy to Content-Duration for Faxes Date: Mon, 7 Feb 2000 11:07:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7185.6CF413EC" Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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_01BF7185.6CF413EC Content-Type: text/plain; charset="windows-1252" At one point we had proposed a 'Content-Length' header specifically for fax page count. I cannot remember if it was ever included in an RFC or not. In practice, we have found it more practical to put thie information in the Subject field. Then the user will see the info in their GUI. Cheers, Glenn. > ---------- > From: Murray, Doug > Sent: Thursday, February 3, 2000 6:11 pm > To: 'Neystadt, John'; vpim@lists.neystadt.org > Subject: RE: [VPIM] Analogy to Content-Duration for Faxes > > Yes, it is very useful to have content duration in meaningful units such > as > seconds of audio (or video), pages of fax, etc. Most e-mail clients will > not > display this information, however. > > The place that this information is most useful is within a TUI where it is > useful to announce the number of pages in a fax, Word document or whatever > so the recipient can decide whether to forward the document to a fax > machine. > > -----Original Message----- > From: Neystadt, John [mailto:John_Neystadt@icomverse.com] > Sent: Thursday, January 27, 2000 3:27 AM > To: vpim@lists.neystadt.org > Subject: [VPIM] Analogy to Content-Duration for Faxes > > > Hi! > > I wonder if anybody came to need of Analogy to Content-Duration for Faxes > to > indicate the number of pages. This is handy to present GUI idication of > fax > size in pages (as in seconds for voice) instead of KBs. > > Does somebody needs this in addition to us? > > Regards, > > John Neystadt > > > > ------_=_NextPart_001_01BF7185.6CF413EC Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable RE: [VPIM] Analogy to Content-Duration for Faxes

At one point we had proposed = a 'Content-Length' header specifically for fax page count.  I = cannot remember if it was ever included in an RFC or not.

In practice, we have found it = more practical to put thie information in the Subject field.  Then = the user will see the info in their GUI.

Cheers,
Glenn.

    ----------
    From:   Murray, Doug
    Sent:   Thursday, February 3, 2000 6:11 pm
    To:     = 'Neystadt, John'; = vpim@lists.neystadt.org
    Subject: =        RE: = [VPIM] Analogy to Content-Duration for Faxes

    Yes, it is very useful to have = content duration in meaningful units such as
    seconds of audio (or video), pages = of fax, etc. Most e-mail clients will not
    display this information, = however.

    The place that this information is = most useful is within a TUI where it is
    useful to announce the number of = pages in a fax, Word document or whatever
    so the recipient can decide whether = to forward the document to a fax
    machine.

    -----Original Message-----
    From: Neystadt, John = [mailto:John_Neystadt@icomver= se.com]
    Sent: Thursday, January 27, 2000 = 3:27 AM
    To: vpim@lists.neystadt.org
    Subject: [VPIM] Analogy to = Content-Duration for Faxes


    Hi!

    I wonder if anybody came to need of = Analogy to Content-Duration for Faxes to
    indicate the number of pages. This = is handy to present GUI idication of fax
    size in pages (as in seconds for = voice) instead of KBs.

    Does somebody needs this in addition = to us?

    Regards,

    John Neystadt




------_=_NextPart_001_01BF7185.6CF413EC-- From owner-ietf-fax@imc.org Mon Feb 7 21:34:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25584 for ; Mon, 7 Feb 2000 21:34:30 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA11366 for ietf-fax-bks; Mon, 7 Feb 2000 17:38:15 -0800 (PST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA11362 for ; Mon, 7 Feb 2000 17:38:13 -0800 (PST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 07 Feb 2000 17:39:27 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <1BSJK3V2>; Mon, 7 Feb 2000 17:39:27 -0800 Message-ID: <7DE119D3D0E15543874F7561EECBDBED01589821@BEG.platinum.corp.microsoft.com> From: Tony Kueh To: "'Glenn Parsons'" , IETF VPIM List Cc: ietf-fax@imc.org Subject: RE: [VPIM] Analogy to Content-Duration for Faxes Date: Mon, 7 Feb 2000 17:40:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF71D5.55E8FE2E" Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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_01BF71D5.55E8FE2E Content-Type: text/plain; charset="iso-8859-1" From an UM perspective, you could potentially have multiple faxes within one message. How would one calculate the total length in the subject field? If it was really part of the subject, then changing the content of a message (ie. forward a fax) would require the update of the subject field. Sounds like a lot of work. Why not just keep the Content-Length header on the body part and have the clients that wish to render a total length to dynamicallly pre-pend it or set it on the rendered subject field on the fly? -----Original Message----- From: Glenn Parsons [mailto:gparsons@nortelnetworks.com] Sent: Monday, February 07, 2000 8:07 AM To: IETF VPIM List Cc: ietf-fax@imc.org Subject: RE: [VPIM] Analogy to Content-Duration for Faxes At one point we had proposed a 'Content-Length' header specifically for fax page count. I cannot remember if it was ever included in an RFC or not. In practice, we have found it more practical to put thie information in the Subject field. Then the user will see the info in their GUI. Cheers, Glenn. ---------- From: Murray, Doug Sent: Thursday, February 3, 2000 6:11 pm To: 'Neystadt, John'; vpim@lists.neystadt.org Subject: RE: [VPIM] Analogy to Content-Duration for Faxes Yes, it is very useful to have content duration in meaningful units such as seconds of audio (or video), pages of fax, etc. Most e-mail clients will not display this information, however. The place that this information is most useful is within a TUI where it is useful to announce the number of pages in a fax, Word document or whatever so the recipient can decide whether to forward the document to a fax machine. -----Original Message----- From: Neystadt, John [ mailto:John_Neystadt@icomverse.com ] Sent: Thursday, January 27, 2000 3:27 AM To: vpim@lists.neystadt.org Subject: [VPIM] Analogy to Content-Duration for Faxes Hi! I wonder if anybody came to need of Analogy to Content-Duration for Faxes to indicate the number of pages. This is handy to present GUI idication of fax size in pages (as in seconds for voice) instead of KBs. Does somebody needs this in addition to us? Regards, John Neystadt ------_=_NextPart_001_01BF71D5.55E8FE2E Content-Type: text/html; charset="iso-8859-1" RE: [VPIM] Analogy to Content-Duration for Faxes
From an UM perspective, you could potentially have multiple faxes within one message. How would one calculate the total length in the subject field? If it was really part of the subject, then changing the content of a message (ie. forward a fax) would require the update of the subject field.
 
Sounds like a lot of work.
 
Why not just keep the Content-Length header on the body part and have the clients that wish to render a total length to dynamicallly pre-pend it or set it on the rendered subject field on the fly?
 
-----Original Message-----
From: Glenn Parsons [mailto:gparsons@nortelnetworks.com]
Sent: Monday, February 07, 2000 8:07 AM
To: IETF VPIM List
Cc: ietf-fax@imc.org
Subject: RE: [VPIM] Analogy to Content-Duration for Faxes

At one point we had proposed a 'Content-Length' header specifically for fax page count.  I cannot remember if it was ever included in an RFC or not.

In practice, we have found it more practical to put thie information in the Subject field.  Then the user will see the info in their GUI.

Cheers,
Glenn.

    ----------
    From:   Murray, Doug
    Sent:   Thursday, February 3, 2000 6:11 pm
    To:     'Neystadt, John'; vpim@lists.neystadt.org
    Subject:        RE: [VPIM] Analogy to Content-Duration for Faxes

    Yes, it is very useful to have content duration in meaningful units such as
    seconds of audio (or video), pages of fax, etc. Most e-mail clients will not
    display this information, however.

    The place that this information is most useful is within a TUI where it is
    useful to announce the number of pages in a fax, Word document or whatever
    so the recipient can decide whether to forward the document to a fax
    machine.

    -----Original Message-----
    From: Neystadt, John [mailto:John_Neystadt@icomverse.com]
    Sent: Thursday, January 27, 2000 3:27 AM
    To: vpim@lists.neystadt.org
    Subject: [VPIM] Analogy to Content-Duration for Faxes


    Hi!

    I wonder if anybody came to need of Analogy to Content-Duration for Faxes to
    indicate the number of pages. This is handy to present GUI idication of fax
    size in pages (as in seconds for voice) instead of KBs.

    Does somebody needs this in addition to us?

    Regards,

    John Neystadt




------_=_NextPart_001_01BF71D5.55E8FE2E-- From owner-ietf-fax@imc.org Tue Feb 8 05:44:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13219 for ; Tue, 8 Feb 2000 05:44:10 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA01438 for ietf-fax-bks; Tue, 8 Feb 2000 02:04:49 -0800 (PST) Received: from alpha.netvision.net.il (alpha.netvision.net.il [194.90.1.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01433 for ; Tue, 8 Feb 2000 02:04:47 -0800 (PST) Received: from sendout.icomverse.com (Efrat-FR3.ser.netvision.net.il [199.203.174.65]) by alpha.netvision.net.il (8.9.3/8.8.6) with ESMTP id MAA22385; Tue, 8 Feb 2000 12:07:33 +0200 (IST) Received: from ismailmkt.icomverse.com (ismailmkt.icomverse.com [190.190.55.28]) by sendout.icomverse.com (8.9.3/8.8.7) with ESMTP id MAA25924; Tue, 8 Feb 2000 12:07:24 +0200 Received: from unity-mail.icomverse.com ([89.119.41.3]) by ismailmkt.icomverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1P8VVTM1; Tue, 8 Feb 2000 12:06:00 +0200 Received: by unity-mail.icomverse.com with Internet Mail Service (5.5.2650.21) id <1GSW588P>; Tue, 8 Feb 2000 12:06:12 +0200 Message-ID: <5B34AF33D291D311A06D0004AC1509D75EAD12@unity-mail.icomverse.com> From: "Neystadt, John" To: IETF VPIM List Cc: ietf-fax@imc.org Subject: RE: [VPIM] Analogy to Content-Duration for Faxes Date: Tue, 8 Feb 2000 12:06:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If I undestand correctly the Content-Duration header is applied not to primary MIME header, but to MIME envelopes of individual body parts. Thus if you have few TIFs or few voice attchements (or mix of each) you can indicate length for each of them. As to overloading the subject, this can be done only because of lack of standard. I the conventional way should be MIME header so that software from different vendors could interoperate. I think Content-Length is bad header to put number of pages, since it used in HTTP to indicate the octet-length of the body part. This would create overloading. So I propose - either to use same Content-Duration (this may be misleading sematically) or to invent another header, like 'Content-Pages:'. John Neystadt john@neystadt.org http://www.neystadt.org/john/ -----Original Message----- From: Tony Kueh [mailto:akueh@Exchange.MICROSOFT.com] Sent: Tue, February 08, 2000 3:40 AM To: 'Glenn Parsons'; IETF VPIM List Cc: ietf-fax@imc.org Subject: RE: [VPIM] Analogy to Content-Duration for Faxes From an UM perspective, you could potentially have multiple faxes within one message. How would one calculate the total length in the subject field? If it was really part of the subject, then changing the content of a message (ie. forward a fax) would require the update of the subject field. Sounds like a lot of work. Why not just keep the Content-Length header on the body part and have the clients that wish to render a total length to dynamicallly pre-pend it or set it on the rendered subject field on the fly? -----Original Message----- From: Glenn Parsons [mailto:gparsons@nortelnetworks.com] Sent: Monday, February 07, 2000 8:07 AM To: IETF VPIM List Cc: ietf-fax@imc.org Subject: RE: [VPIM] Analogy to Content-Duration for Faxes At one point we had proposed a 'Content-Length' header specifically for fax page count. I cannot remember if it was ever included in an RFC or not. In practice, we have found it more practical to put thie information in the Subject field. Then the user will see the info in their GUI. Cheers, Glenn. ---------- From: Murray, Doug Sent: Thursday, February 3, 2000 6:11 pm To: 'Neystadt, John'; vpim@lists.neystadt.org Subject: RE: [VPIM] Analogy to Content-Duration for Faxes Yes, it is very useful to have content duration in meaningful units such as seconds of audio (or video), pages of fax, etc. Most e-mail clients will not display this information, however. The place that this information is most useful is within a TUI where it is useful to announce the number of pages in a fax, Word document or whatever so the recipient can decide whether to forward the document to a fax machine. -----Original Message----- From: Neystadt, John [mailto:John_Neystadt@icomverse.com] Sent: Thursday, January 27, 2000 3:27 AM To: vpim@lists.neystadt.org Subject: [VPIM] Analogy to Content-Duration for Faxes Hi! I wonder if anybody came to need of Analogy to Content-Duration for Faxes to indicate the number of pages. This is handy to present GUI idication of fax size in pages (as in seconds for voice) instead of KBs. Does somebody needs this in addition to us? Regards, John Neystadt From owner-ietf-fax@imc.org Tue Feb 8 10:19:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26457 for ; Tue, 8 Feb 2000 10:19:36 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA08741 for ietf-fax-bks; Tue, 8 Feb 2000 06:46:32 -0800 (PST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08737 for ; Tue, 8 Feb 2000 06:46:30 -0800 (PST) Received: from dns.maillennium.att.com ([135.25.114.99]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id JAA27281 for ; Tue, 8 Feb 2000 09:48:49 -0500 (EST) Received: from att.com ([135.197.86.78]) by maillennium.att.com (labmail) with SMTP id <200002081446290992530118e>; Tue, 8 Feb 2000 14:46:30 +0000 Message-ID: <38A02B6C.161BDA6D@att.com> Date: Tue, 08 Feb 2000 09:42:52 -0500 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: IETF VPIM List , ietf-fax@imc.org Subject: Re: [VPIM] Analogy to Content-Duration for Faxes References: <5B34AF33D291D311A06D0004AC1509D75EAD12@unity-mail.icomverse.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In addition to its use within HTTP, one of the common mailbox formats also uses Content-Length: to hold the number of octets in the message. Systems that use this mailbox format also rewrite any existing content-length: header before storing the message into the mailbox to have the correct number of octets. A different header is definitely in order. People should also be aware of RFC 2076, Common Internet Message Header Fields. (It's currently being updated as draft-palme-mailext-headers-02.txt.) Any proposals for new message headers should be checked against the lists in there to see if they're already being used somewhere else. Tony "Neystadt, John" wrote: > > If I undestand correctly the Content-Duration header is applied not > to primary MIME header, but to MIME envelopes of individual body > parts. Thus if you have few TIFs or few voice attchements (or mix of > each) you can indicate length for each of them. > > As to overloading the subject, this can be done only because of lack > of standard. I the conventional way should be MIME header so that > software from different vendors could interoperate. > > I think Content-Length is bad header to put number of pages, since it > used in HTTP to indicate the octet-length of the body part. This > would create overloading. > > So I propose - either to use same Content-Duration (this may be > misleading sematically) or to invent another header, like > 'Content-Pages:'. From owner-ietf-fax@imc.org Tue Feb 8 11:23:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00056 for ; Tue, 8 Feb 2000 11:23:45 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA10357 for ietf-fax-bks; Tue, 8 Feb 2000 07:47:39 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10350 for ; Tue, 8 Feb 2000 07:47:35 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id KAA14478; Tue, 8 Feb 2000 10:50:02 -0500 (EST) Message-Id: <200002081550.KAA14478@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tony Kueh cc: "'Glenn Parsons'" , IETF VPIM List , ietf-fax@imc.org Subject: Re: [VPIM] Analogy to Content-Duration for Faxes In-reply-to: Your message of "Mon, 07 Feb 2000 17:40:05 PST." <7DE119D3D0E15543874F7561EECBDBED01589821@BEG.platinum.corp.microsoft.com> Date: Tue, 08 Feb 2000 10:50:01 -0500 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Why not just keep the Content-Length header on the body part and have the > clients that wish to render a total length to dynamicallly pre-pend it or > set it on the rendered subject field on the fly? please don't call it Content-Length. That field name is already in use. Keith From owner-ietf-fax@imc.org Tue Feb 8 13:22:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06049 for ; Tue, 8 Feb 2000 13:22:43 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA13801 for ietf-fax-bks; Tue, 8 Feb 2000 09:39:36 -0800 (PST) Received: from laptop (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13796 for ; Tue, 8 Feb 2000 09:39:34 -0800 (PST) Message-Id: <4.2.1.20000208094238.00ace480@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Tue, 08 Feb 2000 09:43:04 -0800 To: ietf-fax@imc.org From: Paul Hoffman / IMC Subject: Fwd: Protocol Action: URLs for Telephone Calls to Proposed Standard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is of interest to this group. >To: IETF-Announce: ; >Cc: RFC Editor >Cc: Internet Architecture Board >From: The IESG >Subject: Protocol Action: URLs for Telephone Calls to Proposed Standard >Date: Tue, 08 Feb 2000 10:24:48 -0500 >Sender: scoya@cnri.reston.va.us > > > >The IESG has approved the Internet-Draft 'URLs for Telephone Calls' > as a Proposed Standard. This has >been reviewed in the IETF but is not the product of an IETF Working >Group. The IESG contact persons are Scott Bradner and Vern Paxson. > > >Technical Summary > > This document specifies URL (Uniform Resource Locator) schemes ''tel'', > ''fax'' and ''modem'' for specifying the location of a terminal in the > phone network and the connection types (modes of operation) that can be > used to connect to that entity. This specification covers voice calls > (normal phone calls, answering machines and voice messaging systems), > facsimile (telefax) calls and data calls, both for POTS and digital/mobile > subscribers. > > The "tel" scheme describes a connection to a terminal that handles normal > voice telephone calls, a voice mailbox or another voice messaging system or > a service that can be operated using DTMF tones. > > The "fax" scheme describes a connection to a terminal that can handle > telefaxes (facsimiles). The name (scheme specifier) for the URL is "fax" as > recommended by ITU-T Recommendation E.123. > > The "modem" scheme describes a connection to a terminal that can handle > incoming data calls. The term "modem" refers to a device that does > digital-to-analog and analog-to-digital conversions; in addition to these, > a "modem" scheme can describe a fully digital connection. > >Working Group Summary > > Although an individual submission this document was reviewed by both the > mmusic and pint working groups. A number of changes were made in the > document in response to comments by members of these working groups and in > response to comments during the IETF Last-Call. > >Protocol Quality > > This document was reviewed for the IESG by Scott Bradner. > > >Note to RFC Editor: > > Please remove the phrase "Contact person and version control > responsibility for this specification:" from Section 7 (Author's address) > > Please remove the phrase: "Please include your name and electronic mail > address in all communications. If you want to receive the newest > version of > this specification electronically, send mail to the address above." > from the > same section 7. >To: IETF-Announce:; >Dcc: ******* >Cc: RFC Editor >Cc: Internet Architecture Board >From: The IESG >Subject: Protocol Action: URLs for Telephone Calls to Proposed Standard >------------- > > >The IESG has approved the Internet-Draft 'URLs for Telephone Calls' > as a Proposed Standard. This has >been reviewed in the IETF but is not the product of an IETF Working >Group. The IESG contact persons are Scott Bradner and Vern Paxson. > > >Technical Summary > > This document specifies URL (Uniform Resource Locator) schemes ''tel'', > ''fax'' and ''modem'' for specifying the location of a terminal in the > phone network and the connection types (modes of operation) that can be > used to connect to that entity. This specification covers voice calls > (normal phone calls, answering machines and voice messaging systems), > facsimile (telefax) calls and data calls, both for POTS and digital/mobile > subscribers. > > The "tel" scheme describes a connection to a terminal that handles normal > voice telephone calls, a voice mailbox or another voice messaging system or > a service that can be operated using DTMF tones. > > The "fax" scheme describes a connection to a terminal that can handle > telefaxes (facsimiles). The name (scheme specifier) for the URL is "fax" as > recommended by ITU-T Recommendation E.123. > > The "modem" scheme describes a connection to a terminal that can handle > incoming data calls. The term "modem" refers to a device that does > digital-to-analog and analog-to-digital conversions; in addition to these, > a "modem" scheme can describe a fully digital connection. > >Working Group Summary > > Although an individual submission this document was reviewed by both the > mmusic and pint working groups. A number of changes were made in the > document in response to comments by members of these working groups and in > response to comments during the IETF Last-Call. > >Protocol Quality > > This document was reviewed for the IESG by Scott Bradner. > > >Note to RFC Editor: > > Please remove the phrase "Contact person and version control > responsibility for this specification:" from Section 7 (Author's address) > > Please remove the phrase: "Please include your name and electronic mail > address in all communications. If you want to receive the newest > version of > this specification electronically, send mail to the address above." > also in > section 7. From owner-ietf-fax@imc.org Tue Feb 8 14:40:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09057 for ; Tue, 8 Feb 2000 14:40:09 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA16608 for ietf-fax-bks; Tue, 8 Feb 2000 11:06:01 -0800 (PST) Received: from mauve.innosoft.com (mauve.innosoft.com [192.160.253.247]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA16604 for ; Tue, 8 Feb 2000 11:06:00 -0800 (PST) From: ned.freed@innosoft.com Received: from MAUVE.INNOSOFT.COM by MAUVE.INNOSOFT.COM (PMDF V6.0-20 #35243) id <01JLNQJZ70Q80005HG@MAUVE.INNOSOFT.COM> for ietf-fax@imc.org; Tue, 08 Feb 2000 11:08:28 -0800 (PST) Date: Tue, 08 Feb 2000 11:07:40 -0800 (PST) Subject: Re: [VPIM] Analogy to Content-Duration for Faxes In-reply-to: "Your message dated Tue, 08 Feb 2000 09:42:52 -0500" <38A02B6C.161BDA6D@att.com> To: Tony Hansen Cc: IETF VPIM List , ietf-fax@imc.org Message-id: <01JLNVAYZSAG0005HG@MAUVE.INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <5B34AF33D291D311A06D0004AC1509D75EAD12@unity-mail.icomverse.com> Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > In addition to its use within HTTP, one of the common mailbox formats > also uses Content-Length: to hold the number of octets in the message. > Systems that use this mailbox format also rewrite any existing > content-length: header before storing the message into the mailbox to > have the correct number of octets. > A different header is definitely in order. A really good point. Content-length, unfortunately, should be avoided at all costs. Ned From owner-ietf-fax@imc.org Tue Feb 8 16:32:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11739 for ; Tue, 8 Feb 2000 16:32:02 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA20060 for ietf-fax-bks; Tue, 8 Feb 2000 12:56:43 -0800 (PST) Received: from sjgw.ipo.att.com (gate.ipo.att.com [135.197.57.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA20056 for ; Tue, 8 Feb 2000 12:56:42 -0800 (PST) Received: from exchsj01.ipo.att.com (exchsj01.ipo.att.com [135.197.41.8]) by sjgw.ipo.att.com (8.8.5/8.8.8) with ESMTP id MAA11885; Tue, 8 Feb 2000 12:58:03 -0800 (PST) Received: from larry (mp-dhcp-2-43.attlabs.att.com [135.197.2.43]) by exchsj01.ipo.att.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DXDVVW61; Tue, 8 Feb 2000 12:56:07 -0800 From: "Larry Masinter" To: "Neystadt, John" , "IETF VPIM List" Cc: Subject: RE: [VPIM] Analogy to Content-Duration for Faxes Date: Tue, 8 Feb 2000 12:58:18 -0800 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.2910.0) In-reply-to: <5B34AF33D291D311A06D0004AC1509D75EAD12@unity-mail.icomverse.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rather than inventing a new header for every kind of content attribute you might want to declare in the header about a particular media element, how about registering a "pages" feature (using RFC 2506), using the Content-Features header (draft-ietf-conneg-content-features-02.txt), and the media feature syntax (RFC 2533) for: Content-Features: pages=10 to note a 10-page document. This requires no overloading, allows interesting combinations of feature expressions, and has a clear extension mechanism which doesn't require creating a new header every time you want to say something new. Larry -- http://larry.masinter.net From owner-ietf-fax@imc.org Tue Feb 8 20:41:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14565 for ; Tue, 8 Feb 2000 20:41:27 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA24587 for ietf-fax-bks; Tue, 8 Feb 2000 17:02:54 -0800 (PST) Received: from mauve.innosoft.com (mauve.innosoft.com [192.160.253.247]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA24580 for ; Tue, 8 Feb 2000 17:02:52 -0800 (PST) From: ned.freed@innosoft.com Received: from MAUVE.INNOSOFT.COM by MAUVE.INNOSOFT.COM (PMDF V6.0-20 #35243) id <01JLNWBQXQW00005HG@MAUVE.INNOSOFT.COM> for ietf-fax@imc.org; Tue, 08 Feb 2000 17:05:26 -0800 (PST) Date: Tue, 08 Feb 2000 17:03:55 -0800 (PST) Subject: RE: [VPIM] Analogy to Content-Duration for Faxes In-reply-to: "Your message dated Tue, 08 Feb 2000 12:58:18 -0800" To: Larry Masinter Cc: "Neystadt, John" , IETF VPIM List , ietf-fax@imc.org Message-id: <01JLO7RJH2D40005HG@MAUVE.INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 References: <5B34AF33D291D311A06D0004AC1509D75EAD12@unity-mail.icomverse.com> Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Rather than inventing a new header for every kind of > content attribute you might want to declare in the > header about a particular media element, how about registering > a "pages" feature (using RFC 2506), using the Content-Features > header (draft-ietf-conneg-content-features-02.txt), and the > media feature syntax (RFC 2533) for: Good point, and an excellent idea. I fully support it. > Content-Features: pages=10 > to note a 10-page document. Might even want to have an additional attribute to say what sort of "page" you're talking about. Ned From owner-ietf-fax@imc.org Wed Feb 9 22:19:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01333 for ; Wed, 9 Feb 2000 22:19:08 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA11687 for ietf-fax-bks; Wed, 9 Feb 2000 18:33:10 -0800 (PST) Received: from sjgw.ipo.att.com (gate.ipo.att.com [135.197.57.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA11682 for ; Wed, 9 Feb 2000 18:33:09 -0800 (PST) Received: from exchsj01.ipo.att.com (exchsj01.ipo.att.com [135.197.41.8]) by sjgw.ipo.att.com (8.8.5/8.8.8) with ESMTP id SAA05666; Wed, 9 Feb 2000 18:34:38 -0800 (PST) Received: from ugnfw (ugnfw-qfe3.ipo.att.com [135.197.40.41]) by exchsj01.ipo.att.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DXDVV03L; Wed, 9 Feb 2000 18:32:41 -0800 From: "Larry Masinter" To: Cc: "Neystadt, John" , "IETF VPIM List" , Subject: RE: [VPIM] Analogy to Content-Duration for Faxes Date: Wed, 9 Feb 2000 18:34:39 -0800 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.2910.0) In-Reply-To: <01JLO7RJH2D40005HG@MAUVE.INNOSOFT.COM> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit # > Content-Features: pages=10 # > to note a 10-page document. # Might even want to have an additional attribute to say what sort of "page" # you're talking about. RFC 2534 already registers 'ua-media' tag with values such as 'screen-paged' and 'stationery' (most likely the kind of pages you'd want with faxes), and a 'paper-size' tag with additional token values. At the time RFC 2534 was written, we were focusing mainly on media features for recipients rather than for content; you might still want to characterize a fax recipient as having a maximum number of pages its willing to receive, though. From owner-ietf-fax@imc.org Mon Feb 14 19:11:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27156 for ; Mon, 14 Feb 2000 19:11:01 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA25078 for ietf-fax-bks; Mon, 14 Feb 2000 15:35:11 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25058; Mon, 14 Feb 2000 15:34:23 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id SAA00271; Mon, 14 Feb 2000 18:37:05 -0500 (EST) Message-Id: <200002142337.SAA00271@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: apps area chairs and working groups: ; cc: ietf@ietf.org reply-to: ietf@ietf.org From: Keith Moore Subject: IETF Adelaide and interim meetings for APPS WGs Date: Mon, 14 Feb 2000 18:37:05 -0500 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It has come to the attention of the Applications Area Directors that one or more Applications area working groups have elected to not meet in Adelaide, and instead to hold an "interim meeting" in the United States, presumably because of distance and/or cost issues. IETF is an international organization, and it is IETF's longstanding practice to hold its meetings in various locations around the planet. This serves both to encourage wider participation in IETF and also to more fairly distribute travel costs and inconvenience (over time) among all participants. The scheduleing of an interim WG meeting in the US in lieu of a WG meeting in Adelaide undermines this policy. This is insulting to non-US participants of IETF (many of whom have attended meetings in the US for years), embarassing to IETF as a whole, and a threat to IETF's international stature. Even if a working group has few participants outside the United States, a working group does not work in isolation from other working groups. Attendance at IETF meetings is an invaluable mechanism for cross-group collaboration. RFC 2418 states: Interim meetings are subject to the same rules for advance notification, reporting, open participation, and process, which apply to other working group meetings. Since normal working group meetings require advance notification via email to the entire IETF list, and the process for getting a meeting slot involves prior approval of the Area Directors, the same requirements apply to interim working group meetings. Part of the reason for prior approval being required is to ensure that the locations of the meetings are not being chosen to favor certain participants over others. There have been several violations of this policy since publication of RFC 2418. Therefore, - All interim meetings within the Applications Area which were not previously and explicitly approved by the Applications Area Directors, are hereby cancelled. - No Applications Area group will hold any interim meeting prior to April 15. - No Applications Area group which does not hold a meeting in Adelaide, will hold any interim meeting prior to July 31. (i.e. prior to the Pittsburg IETF meeting) - This applies to all face to face meetings held for the purpose of conducting working group discussion and to which the working group is invited, even if labelled "informal" or otherwise labelled to distinguish them from official working group meetings. - Exceptions to this policy may be made for recently chartered groups, but Area Director approval is still required for such groups to schedule interim meetings. for the Applications Area Directors, Keith Moore From owner-ietf-fax@imc.org Tue Feb 15 19:11:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28459 for ; Tue, 15 Feb 2000 19:11:20 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA06810 for ietf-fax-bks; Tue, 15 Feb 2000 14:50:25 -0800 (PST) Received: from mis2.centigram.com (pix76.centigram.com [198.137.183.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06806 for ; Tue, 15 Feb 2000 14:50:23 -0800 (PST) From: Eric.Burger@centigram.com Received: from notes.centigram.com (notes.centigram.com [129.1.11.64]) by mis2.centigram.com (8.9.1/8.9.1) with SMTP id OAA20387; Tue, 15 Feb 2000 14:53:16 -0800 (PST) Received: by notes.centigram.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 88256886.007E25DF ; Tue, 15 Feb 2000 14:57:52 -0800 X-Lotus-FromDomain: CENTIGRAM To: VPIM-L@listmail.ema.org, ietf-fax@imc.org, internet-drafts@ietf.org Message-ID: <88256886.007E25AB.00@notes.centigram.com> Date: Tue, 15 Feb 2000 14:55:46 -0800 Subject: draft-ema-vpim-pndn-01.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Network Working Group E. Burger Internet Draft Centigram Communications Corporation Document: draft-ema-vpim-pndn-01.txt February 15, 2000 Category: Standards Track Expires in six months Partial Non-Delivery Notification Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Other documents may update, replace, or obsolete this document at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document describes the interaction between systems sending multi-part Internet mail [2] to systems that cannot render parts of the sent message. In particular, this document describes an extension to the Delivery Status Notification mechanism described in [3]. An example of partial message delivery failure is the case when a user sends an audio file and a video file to an Internet Voice Mail [4] system. The Internet Voice Mail system can render the audio part but not the video part. In this case, a partial delivery occurs. This document reflects work undertaken in support of the Internet Voice Mail and Voice Profile for Internet Mail [5] initiatives. The VPIM Work Group home page is . Burger Expires 7/11/2000 [Page 1] Partial Non-Delivery Notification January 11, 2000 Table of Contents 1. Abstract .....................................................1 2. Conventions used in this document ............................2 3. Introduction .................................................3 4. Operation ....................................................5 5. Contents of the PNDN .........................................6 5.1. The message/partial-delivery-status content-type ..........6 5.2. Per-Message PNDN Fields ...................................7 5.2.1. Fields from RFC 1894 .................................7 5.2.2. Original-Message-ID ..................................7 5.3. Per-Part PNDN Fields ......................................8 5.3.1. Fields from RFC 1894 .................................9 5.3.2. Action Field .........................................9 5.3.3. Final Recipient Field ...............................10 5.3.4. Original Content ID Field ...........................10 5.3.5. Original Content Description Field ..................10 5.3.6. Original Content Disposition Field ..................10 5.3.7. Original Content Type Field .........................10 5.3.8. Status Field ........................................11 6. Appendix - Examples .........................................12 6.1. PNDN With One Failed Body Part ...........................13 6.2. PNDN With Two Failed Body Parts ..........................14 6.3. PNDN With One Body Part Failure and Two Recipients .......15 6.4. PNDN With One Body Part Failure for One Recipient and Another Body Part Failure for Two Recipients .............16 7. Formal Syntax ...............................................18 8. Security Considerations .....................................19 8.1. Forgery ..................................................19 8.2. Confidentiality ..........................................20 9. References ..................................................21 10. Acknowledgments .............................................22 11. Author's Address ............................................22 12. Notices and Full Copyright Statement ........................23 2. Conventions used in this document This document refers generically to the sender of a message in the masculine (he/him/his) and the recipient of the message in the feminine (she/her/hers). This convention is purely for convenience and makes no assumption about the gender of a message sender or recipient. Burger Internet Draft - Expires 7/11/2000 [Page 2] Partial Non-Delivery Notification January 11, 2000 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [6]. FORMATTING NOTE: Notes, such at this one, provide additional nonessential information that the reader may skip without missing anything essential. The primary purpose of these non-essential notes is to convey information about the rationale of this document, or to place this document in the proper historical or evolutionary context. Readers whose sole purpose is to construct a conformant implementation may skip such information. However, it may be of use to those who wish to understand why we made certain design choices. 3. Introduction This document describes partial non-delivery notifications (PNDN). Partial non-delivery notifications are an extension of the Delivery Status Notification (DSN) described in RFC 1894 [3]. The need for a partial non-delivery notification comes about because of the internetworking of Internet mail systems with legacy messaging systems that do not fulfil all of the semantics of Internet mail. Such legacy systems have a limited ability to render all parts of a given message. This document will use the case of an Internet mail system sending electronic messages a legacy voice messaging system for illustrative purposes. Electronic mail has historically been text-centric. Extensions such as MIME enable the desktop to send and receive multi-part, multimedia messages. Popular multimedia data types include binary word processing documents, binary business presentation graphics, voice, and video. Voice mail has historically been audio-centric. Many voice messaging systems can only render voice. Extensions such as fax enable the voice mail system to send and receive fax images as well as create multi-part voice and fax messages. A few voice mail systems can render text using text-to-speech or text-to-fax technology. Although theoretically possible, none can today render video. An important aspect of the interchange between voice messaging services and desktop e-mail client applications is that the rendering capability of the voice messaging platform is often much less than the rendering capability of a desktop e-mail client. In the e-mail case, the sender has the expectation that the recipient receives all components of a multimedia message. This is so even if the recipient cannot render all body parts. For the most part, the Burger Internet Draft - Expires 7/11/2000 [Page 3] Partial Non-Delivery Notification January 11, 2000 recipient can either find the appropriate rendering tool or tell the sender that she cannot read the particular attachment. This is an important issue. By definition, a MIME-enabled user agent, conforming to [7] will present or make available all of the body parts to the recipient. However, a voice mail system may not be capable of storing non-voice objects. Moreover, the voice mail system may not be capable of notifying the recipient that there were undeliverable message parts. The inability of the receiving system to render a body part is usually a permanent failure. Retransmission of the message will not improve the likelihood of a future successful delivery. Contrast this to the case with normal data delivery. Traditional message failures, such as a garbled message or disabled link will benefit from retransmission. Note that the PNDN does not attempt to address User Agent failures, such as a corruption of a body part. PNDN only addresses the capability of a system to handle the data type by observing the part's metadata. Other mechanisms, such as Message Disposition Notification [8], can address the situation when the recipient system discovers an error in the payload of a body part. This document addresses the need to allow Internet e-mail client applications to send arbitrary multi-part multimedia messages to voice messaging systems, retaining the semantics of delivery notification, while taking into account the limitations of the voice messaging system's rendering capabilities. The method described by this document is applicable to any interface between a full-featured user agent and a recipient mail transfer agent that has less rendering and media type storage capabilities than the sender has. Ideally, the voice mail system would notify the recipient of the undeliverable body parts. Such behavior would satisfy the essential requirements of [8]. In fact, if the voice mail system can notify the recipient there were undeliverable body parts, then there would be no need for this document. However, many voice mail systems are not capable of making this notification. NOTE: An alternative method of handling partial delivery is to determine what parts of the message the sender considers critical. If the voice mail system could not deliver the critical parts, then the voice mail system would reject the entire message. If the voice mail system could deliver the critical parts, but there were other undeliverable parts, it would silently delete the parts from the delivered message. The VPIM work group determined this method, in practice, would be too complex to implement and would have the drawback of the voice mail system silently deleting message components. In light of the limitations of voice mail systems, we decided to deliver as much of the message as possible, notifying the sender of any parts that the voice mail system fails to deliver. Burger Internet Draft - Expires 7/11/2000 [Page 4] Partial Non-Delivery Notification January 11, 2000 NOTE: The concept of a critical part indicator is still a useful construction. The sender may wish to specify a body part as so important that if the system cannot deliver the specified body part, then the system will not deliver any parts of the message. However, this is beyond the scope of this document. We should revisit this issue once there is an acceptable mechanism for identifying critical parts. 4. Operation The sending system sees the Internet Voice Mail system as a peer e- mail client. The only special consideration on the part of the sending system is that it may encode the MIME message following the format specified by VPIM [5] or the Internet Voice Mail Profile [4]. Properly encoding and profiling the message will enhance the receiving system's ability to process and successfully deliver the message. Such considerations include the formatting and encoding of the sender's audio name clip, return address information, out-dial destinations, and other elements. Refer to [5] for more information. The recipient system, on receipt of e-mail destined for a voice mail user, makes a best-efforts attempt to deliver what parts it can to the user. If the recipient system is capable of delivering the entire message, it follows the notification protocols specified in [4]. If the recipient system cannot deliver any part of the message, it will return the non-delivery notification specified in [4]. If the recipient system is capable of delivering only part of the message, it will return a partial non-delivery notification (PNDN) as described below. Delivery failure can occur for all recipients of a message because the recipient system cannot handle a given body part. However, body-part delivery failure can also occur for a subset of recipients of a message. This happens if the recipient system is capable of handling the media type of the body part, but the recipient user does not subscribe to a service that can present the media type. For example, consider an Internet Voice Mail platform that can handle fax. Now consider a service provider that has a class of service that is voice only. If the message recipient user has a voice only class of service, she will not be able to render fax, which is an image. Burger Internet Draft - Expires 7/11/2000 [Page 5] Partial Non-Delivery Notification January 11, 2000 NOTE: We chose Delivery Status Notification (DSN) [3] over Message Disposition Notification (MDN) [8] as a model for PNDN. There was some discussion on this point because an Internet Voice Mail system acts as both a UA and a MTA. The Message Disposition Notification deals with things such as return receipt. The generation of the return receipt can occur long after the receiving system has received the message. On the other hand, the receiving system can know on receipt whether it has the capabilities to deliver all parts of the message. In this case, the recipient acts more like an MTA than a UA. In addition, we decided it was more important for the sender to know the system would never deliver some parts of the message. It would not be desirable to wait for the recipient to attempt to read the message and only at that point generate a notification that the system could not deliver parts of the message. NOTE: This is why the language uses "is capable of delivering" rather than "delivers" in the description above. 5. Contents of the PNDN The PNDN informs a human or machine sender that the recipient system could not deliver one or more parts of a message they have sent. The PNDN is a special case of Delivery Status Notification. In the sections that follow, refer to [3] for a full description of the fields. The receiving system transmits a PNDN as a MIME message with a top- level content-type of multipart/report, as defined in [3]. The mail system can use the multipart/report content-type for any of several kinds of reports. For a PNDN, the report-type parameter uses the DSN multipart/report content-type of "delivery-status". As described in [9], the first part of a multipart/report content- type is a human readable explanation of the report. For a PNDN, the second component of the multipart/report is of content-type message/delivery-status. The third component of the multipart/report consists of the original message or some portion thereof. 5.1. The message/delivery-status content-type The message/delivery-status content-type definition is as follows: MIME type name: message MIME subtype name: delivery-status Burger Internet Draft - Expires 7/11/2000 [Page 6] Partial Non-Delivery Notification January 11, 2000 Optional parameters: none. Encoding considerations: "7bit" encoding is sufficient and conforming systems MUST use it to maintain readability when viewed by non-MIME mail readers. Security considerations: discussed in section 7 of this memo. The message/delivery-status report type for use in the multipart/report is "delivery-status". The body of a message/delivery-status consists of one or more "fields" formatted according to the ABNF [10] specified below and in [3]. The per-message fields appear first, followed by a blank line. Following the per-message fields are one or more groups of per- recipient/per-body part fields. A blank line precedes each group of per-recipient fields. The syntax of the message/delivery-status content is in section 7. Section 5.2 describes the per-message-fields. Section 5.3 describes the per-part-fields. NOTE: Readers should focus on Section 5.3 as it describes the essential extensions to DSN. 5.2. Per-Message PNDN Fields 5.2.1. Fields from RFC 1894 Except as noted below, the PNDN contains all fields as appropriate from DSN [3]. In particular, Reporting-MTA MUST be present. NOTE: The sender's MTA could generate a DSN. In this case, the Reporting-MTA is optional. However, only receiving systems will generate Partial Non-Delivery Notifications. Thus, the sender needs to know who reported the failure. 5.2.2. Original-Message-ID The recipient system MUST generate an Original-Message-ID field if a Message-ID field was present in the original message. NOTE: This is a change from RFC 1894. Few User Agents insert an Envelope-ID. The sender needs to know what message failed. Sending back the original message in a multimedia environment has security implications. In particular, requiring the receiving system to send back large multimedia files would make them vulnerable to denial of Burger Internet Draft - Expires 7/11/2000 [Page 7] Partial Non-Delivery Notification January 11, 2000 service attacks. Moreover, MIME-encoded body parts are in base64. Since we cannot rely on the user recognizing the original text of their message, we must rely on alternative identifying characteristics. 5.3. Per-Part PNDN Fields A PNDN contains information about attempts to deliver a message's parts to one or more recipients. A group of contiguous per-message, per-recipient body-part content partial non-delivery notification fields contains delivery information for that body-part. A blank line precedes each group of per-part fields. PNDN expands upon DSN by introducing body part indicators to DSN's per-recipient block. This extension allows multiple recipients per per-recipient block and multiple body part indicators per per- recipient block. A conforming implementation may choose to separate each body-part / recipient failure into its own per-recipient block. A conforming PNDN parser MUST be able to digest each of the three reporting types. For example, take a message sent to two users, A and B. In addition, let's say that Part 1 fails for the same reason for both users, and Part 2 fails only for user B for the same reason Part 1 failed. Here are three, equivalent ways of rendering the per- recipient block. 1. Enumerate all failures individually: Recipient A Failure Part 1 Failure Recipient B Failure Part 1 Failure Recipient B Failure Part 2 Failure 2. Group by recipient: Recipient A Failure Part 1 Failure Recipient B Failure Part 1 Failure Part 2 Failure 3. Group by part: Burger Internet Draft - Expires 7/11/2000 [Page 8] Partial Non-Delivery Notification January 11, 2000 Recipient A Failure Recipient B Failure Part 1 Failure Recipient B Failure Part 2 Failure NOTE: This RFC could have required enumeration as the only way to report failures. This makes for a cleaner standard. However, consider the case of a message sent to a large number of recipients. Assuming each recipient / part combination has the same failure mode, expanding all of the redundant information, such as the part identification, for each recipient greatly increases the size of the PNDN. 5.3.1. Fields from RFC 1894 Except as noted below, the PNDN contains all fields as appropriate from DSN [3]. The Original-Recipient, Final-Recipient, Last- Attempt-Date, and Final-Log-ID fields follow their meaning and requirements set forth in DSN. The Will-Retry-Until field is not relevant, as the PNDN is not a delayed delivery notification. 5.3.2. Action Field The action field reflects the disposition of the message. Since the receiving system can deliver at least part of the message, the action value SHOULD be "delivered". If the recipient system did not deliver any parts of the message, then it would perform the normal undeliverable message processing described by DSN [3]. NOTE: Considering partial delivery a failure or a success is a matter of many debates. There is work ongoing in the IETF to develop an indicator for identifying critical body parts. With a critical body part indicator, the recipient system can return to the sender a success or failure indication based on whether or not the system succeeded in delivering the critical parts. Without critical part indicators, one may chose to err on the side of failing the entire message. However, from a practical point of view, the sender probably will have some idea of the capabilities of the recipient. Moreover, experience shows that users do not take well to being bombarded with failure notices they believe should be warnings. Therefore, until such a time as we have a critical body part indicator, the best practice is to return a delivered notice to the sender, with the appropriate warning and explanation message for the body part(s) not delivered. Burger Internet Draft - Expires 7/11/2000 [Page 9] Partial Non-Delivery Notification January 11, 2000 5.3.3. Final Recipient Field The Final-Recipient field indicates the recipient for which this set of per-part fields applies. The definition of the final recipient field is as described by DSN [3]. However, for security reasons, the PNDN relaxes the imperative for including this field. That is, the per-part data MAY include the final recipient field NOTE: The change in imperative from [3], from MUST to MAY, comes from the Internet Voice Mail environment. One can envision Internet Voice Mail implementations where the service provider wishes to keep the actual host name of the voice mail system hidden yet in the Internet name space. Reporting the final recipient field may include the actual host name of a voice mail node. Making that information public through a PNDN may enable attacks on that node. 5.3.4. Original Content ID Field This field, if present in the original message, MUST be present in the PNDN. It aids the sender in understanding exactly which body part the receiving system is not capable of delivering. 5.3.5. Original Content Description Field This field, if present in the original message, MUST be present in the PNDN. It aids the sender in understanding exactly which body part the receiving system is not capable of delivering. This field will be much more useful than the Original-Content-ID field to a human sender. However, few User Agents insert the Content- Description field in a message. 5.3.6. Original Content Disposition Field This field, if present in the original message, MAY be present in the PNDN if there is a Content Type field in the original message. This field MUST be present if there is not a Content Type field in the original message and the content disposition field contains a filename. This field aids the sender in understanding exactly which body part the receiving system is not capable of delivering. This field will be more useful than the Original-Content-ID field to a human sender. It will let the human know the file name of the part the receiving system is not capable of handling. 5.3.7. Original Content Type Field This field, if present in the original message, MUST be present in the PNDN. It aids the sender in understanding exactly which body Burger Internet Draft - Expires 7/11/2000 [Page 10] Partial Non-Delivery Notification January 11, 2000 part the receiving system is not capable of delivering. This field will be much more useful than the Original-Content-ID field to a human sender. It will let the human know the MIME types that the receiving system is not capable of handling. In addition, the sender will get a clue as to what body part the receiving system is not capable of handling from the filename sub-field, if present. 5.3.8. Status Field Message Transfer Agents (MTAs) are free to generate standard status codes from [11]. This section describes status codes that have special meaning for PNDN. All of these status codes are of type "permanent failures of media", type 5. Receiving systems that generate Partial Non-Delivery Notifications MUST insert descriptive text in the comment field of the status code so a human sender can understand why his message failed. Sending systems that automatically process returned status codes MUST use the numeric status code and MUST NOT use the comment. 5.3.8.1. Media not Supported If the recipient system is not capable of delivering a part of a message because it does not support a given media type, it MUST return the Media not Supported status code. For example, if an Internet Voice Mail system receives an AutoCAD document and it can only render voice, the Internet Voice Mail system will return a Media not Supported status code. 5.3.8.2. Conversion With Loss Performed If the recipient system can deliver the part, but only with a lossy conversion, the receiving system SHOULD NOT return Conversion With Loss Performed. NOTE: We considered the optional return code of Conversion With Loss Performed, Status 5.6.4. However, we realized two things. First, few Internet Voice Mail systems would necessarily have the capability of generating this warning. Second, there is dubious value to the sender of receiving this warning. If the receiver has trouble understanding the rendering of the body part, she can always send a message to the sender. On the other hand, we could foresee confusion on the part of the sender if he constantly received warning messages every time he sends a message to the particular recipient. Burger Internet Draft - Expires 7/11/2000 [Page 11] Partial Non-Delivery Notification January 11, 2000 6. Appendix - Examples NOTE: These examples are for illustrative purposes only and are not a normative part of the PNDN definition. If an example conflicts with the normative description of sections 3 through 5, the example is wrong. The examples in this appendix use the following MIME-Encoded message for the original sent message. The message has three parts. The first part is a text message. The second part is a voice message. The third part is a fax message. Here is the sample message. Message-ID: 005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com From: "Eric Burger" To: "Eric Burger" Subject: Three-part Message Date: Mon, 22 Nov 1999 12:02:30 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01BF34E1.74123720" X-Priority: 3 X-Mailer: The One And Only Test Platform V8.1222.974B This is a multi-part message in MIME format. ------=_NextPart_000_0007_01BF34E1.74123720 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-ID: TextPart0AFF8B Here is a three-part message. The first part is text (this one). The second part is voice. The third part is fax. ------=_NextPart_000_0007_01BF34E1.74123720 Content-Type: audio/wav; name="Voice Message.wav" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Voice Message.wav" UklGRjgRAABXQVZFZm10IBQAAAAxAAEAQB8AAFkGAABBAAAAAgBAAWZhY3QEAAAAwFMA EQAASfYQFoWCEkuSTST3JGyiTbIfDybr9hltilsnh+uBo/OEpE1iTFGWuFEcFJFuVAxk Burger Internet Draft - Expires 7/11/2000 [Page 12] Partial Non-Delivery Notification January 11, 2000 ... 0TIT1twS7JVeyYHHFDaWIEN1mcYMlvLNgGoakdxbL2ErxZprJS+htNhu4ozNYKmwCGvT wErbIgazEvRAGn5hMxhcqGS59UE1cHEjR08A ------=_NextPart_000_0007_01BF34E1.74123720 Content-Type: image/tiff; name="My House.tif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="My House.tif" Content-Description: Picture of My House SUkqABhSAAAAAU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAFN AU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAGRqDuH4JefU8/YSwd8/xdn7CKC4PMW ... UAAAGgEFAAEAAAAIUgAAGwEFAAEAAAAQUgAAJAEEAAEAAAAEAAAAKAEDAAEAAAACAAAA AAAAAAEARgEDAAEAAAAAAAAARwEDAAEAAAAAAAAAAAAAAA== ------=_NextPart_000_0007_01BF34E1.74123720-- 6.1. PNDN With One Failed Body Part This example shows a PNDN for a system that does not handle text, but does handle voice and fax. Date: Thu, 22 Nov 1999 09:05:15 -0800 From: Mail Delivery Subsystem Message-Id: <199407072116.RAA14128@TELECNNCT> Subject: WARNING: Could Not Delivery Body Part To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="RAA14128.773615765/CENTIGRAM.COM" --RAA14128.773615765/CENTIGRAM.COM The original message was received at Mon, 22 Nov 1999 09:05:05 -0800 from root@localhost ----- The following addresses had delivery problems ----- (warning) ----- Transcript of session follows ----- Could Not Deliver Text Part to < eric.burger@centigram.com > Body part will be deleted from queue --RAA14128.773615765/CENTIGRAM.COM Burger Internet Draft - Expires 7/11/2000 [Page 13] Partial Non-Delivery Notification January 11, 2000 content-type: message/delivery-status Original-Message-ID: 005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com Reporting-MTA: dns; telecnnct.com Action: delivered Status: 5.6.1 (Media not Supported) Original-Recipient: rfc822;eric.burger@centigram.com Original-Content-ID: TextPart0AFF8B --RAA14128.773615765/CENTIGRAM.COM content-type: message/rfc822 Here is a three-part message. The first part is text (this one). The second part is voice. The third part is fax. --RAA14128.773615765/CENTIGRAM.COM-- 6.2. PNDN With Two Failed Body Parts This example shows a PNDN for a system that does not handle text or fax. Date: Thu, 22 Nov 1999 09:05:15 -0800 From: Mail Delivery Subsystem Message-Id: <199407072116.RAA14128@TELECNNCT> Subject: WARNING: Could Not Delivery Body Part To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="RAA14128.773615765/CENTIGRAM.COM" --RAA14128.773615765/CENTIGRAM.COM The original message was received at Mon, 22 Nov 1999 09:05:05 -0800 from root@localhost ----- The following addresses had delivery problems ----- (warning) ----- Transcript of session follows ----- Could Not Deliver Text Part to < eric.burger@centigram.com > Could Not Deliver Fax Part to < eric.burger@centigram.com > Body parts will be deleted from queue Burger Internet Draft - Expires 7/11/2000 [Page 14] Partial Non-Delivery Notification January 11, 2000 --RAA14128.773615765/CENTIGRAM.COM content-type: message/delivery-status Original-Message-ID: 005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com Reporting-MTA: dns; telecnnct.com Original-Recipient: rfc822;eric.burger@centigram.com Status: 5.6.1 (Media not Supported) Action: delivered Original-Content-ID: TextPart0AFF8B Original-Recipient: rfc822;eric.burger@centigram.com Status: 5.6.1 (Media not Supported) Action: delivered Original-Content-Description: Picture of My House Original-Content-Type: image/tiff; name="My House.tif" Original-Content-Disposition: attachment; filename="My House.tif" --RAA14128.773615765/CENTIGRAM.COM content-type: message/rfc822 Here is a three-part message. The first part is text (this one). The second part is voice. The third part is fax. --RAA14128.773615765/CENTIGRAM.COM-- 6.3. PNDN With One Body Part Failure and Two Recipients This example shows a PNDN for a system that does not handle text, but does handle voice and fax. Assume the original message was sent to and <8005551212@vm.sp.net>. Date: Thu, 22 Nov 1999 09:05:15 -0800 From: Mail Delivery Subsystem Message-Id: <199407072116.RAA14128@TELECNNCT> Subject: WARNING: Could Not Delivery Body Part To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="RAA14128.773615765/CENTIGRAM.COM" --RAA14128.773615765/CENTIGRAM.COM The original message was received at Mon, 22 Nov 1999 09:05:05 -0800 from root@localhost Burger Internet Draft - Expires 7/11/2000 [Page 15] Partial Non-Delivery Notification January 11, 2000 ----- The following addresses had delivery problems ----- (warning) <8005551212@vm.sp.net> (warning) ----- Transcript of session follows ----- Could Not Deliver Text Part to < eric.burger@centigram.com > Could Not Deliver Text Part to < 8005551212@vm.sp.net > Body part will be deleted from queue --RAA14128.773615765/CENTIGRAM.COM content-type: message/delivery-status Original-Message-ID: 005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com Reporting-MTA: dns; telecnnct.com Action: delivered Status: 5.6.1 (Media not Supported) Original-Recipient: rfc822;eric.burger@centigram.com Original-Recipient: rfc822;8005551212@vm.sp.net Final-Recipient: rfc822;eburger@vmail27.sp.net Original-Content-ID: TextPart0AFF8B --RAA14128.773615765/CENTIGRAM.COM content-type: message/rfc822 Here is a three-part message. The first part is text (this one). The second part is voice. The third part is fax. --RAA14128.773615765/CENTIGRAM.COM-- 6.4. PNDN With One Body Part Failure for One Recipient and Another Body Part Failure for Two Recipients This example shows a PNDN for a system that does not handle text, but does handle voice and fax. However, the recipient at ericb@mtc.telecnnct.com does not subscribe to a fax service. Assume the original message was sent to and <8005551212@vm.sp.net>. Date: Thu, 22 Nov 1999 09:05:15 -0800 From: Mail Delivery Subsystem Message-Id: <199407072116.RAA14128@TELECNNCT> Subject: WARNING: Could Not Delivery Body Part To: MIME-Version: 1.0 Burger Internet Draft - Expires 7/11/2000 [Page 16] Partial Non-Delivery Notification January 11, 2000 Content-Type: multipart/report; report-type=delivery-status; boundary="RAA14128.773615765/CENTIGRAM.COM" --RAA14128.773615765/CENTIGRAM.COM The original message was received at Mon, 22 Nov 1999 09:05:05 -0800 from root@localhost ----- The following addresses had delivery problems ----- (warning) <8005551212@vm.sp.net> (warning) ----- Transcript of session follows ----- Could Not Deliver Text Part to < eric.burger@centigram.com > Could Not Deliver Text Part to < 8005551212@vm.sp.net > Could Not Deliver Fax Part to < eric.burger@centigram.com > Body part will be deleted from queue --RAA14128.773615765/CENTIGRAM.COM content-type: message/delivery-status Original-Message-ID: 005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com Reporting-MTA: dns; telecnnct.com Action: delivered Status: 5.6.1 (Media not Supported) Original-Recipient: rfc822;eric.burger@centigram.com Original-Recipient: rfc822;8005551212@vm.sp.net Final-Recipient: rfc822;eburger@vmail27.sp.net Original-Content-ID: TextPart0AFF8B Action: delivered Status: 5.6.1 (Media not Supported) Original-Recipient: rfc822;8005551212@vm.sp.net Final-Recipient: rfc822;eburger@vmail27.sp.net Original-Content-Description: Picture of My House Original-Content-Type: image/tiff; name="My House.tif" Original-Content-Disposition: attachment; filename="My House.tif" --RAA14128.773615765/CENTIGRAM.COM content-type: message/rfc822 Here is a three-part message. The first part is text (this one). The second part is voice. The third part is fax. --RAA14128.773615765/CENTIGRAM.COM-- Burger Internet Draft - Expires 7/11/2000 [Page 17] Partial Non-Delivery Notification January 11, 2000 7. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [10]. delivery-status-content = per-message-fields 1*( CRLF per-part-fields) 7.1. Syntax of Per-Message Fields per-message-fields = [ original-message-id-field CRLF ] [ original-envelope-id-field CRLF ] reporting-mta-field CRLF [ dsn-gateway-field CRLF ] [ received-from-mta-field CRLF ] [ arrival-date-field CRLF ] *( extension-field CRLF ) original-message-id-field = "Original-Message-ID" ":" message-id message-id = *text Original-envelope-id-field, reporting-mta-field, dsn-gateway-field, received-from-mta-field, arrival-date-field, and extension-field are all as defined in DSN [3]. 7.2. Syntax of Per-Part Fields per-part-fields = 1*( [ original-content-description-field CRLF ] [ original-content-id-field CRLF ] [ original-content-disposition-field CRLF ] [ original-content-type-field CRLF ] ) 1*( [ original-recipient-field CRLF ] final-recipient-field CRLF ) action-field CRLF status-field CRLF [ remote-mta-field CRLF ] [ diagnostic-code-field CRLF ] [ last-attempt-date-field CRLF ] *( extension-field CRLF ) action-field = "Action: delivered" Burger Internet Draft - Expires 7/11/2000 [Page 18] Partial Non-Delivery Notification January 11, 2000 original-content-id-field = "Original-Content-ID" ":" content-id content-id = *text original-content-description-field = "Original-Content-Description" ":" content-description content-description = *text original-content-disposition-field = "Original-Content-Disposition" ":" content-disposition content-disposition = *text original-content-type-field = "Original-Content-Type" ":" content-type content-type = *text status-field = "Status: 5.6.1" "(" comment ")" comment = *text Original-recipient-field, final-recipient-field, remote-mta-field, diagnostic-code-field, last-attempt-date-field, and extension-field are as defined in DSN [3]. 8. Security Considerations The following security considerations apply when using PNDNs: 8.1. Forgery One can forge a PNDN as easily as ordinary Internet electronic mail. User agents and automatic mail handling facilities (such as automatic voice mail forwarding agents) that wish to make use of PNDNs should take appropriate precautions to minimize the potential damage from denial-of-service attacks. Security threats related to forged PNDNs include the sending of: (a) A falsified delivery notification when the message is not delivered to the indicated recipient, (b) A falsified Final-Recipient address, or (c) A falsified Remote-MTA identification. Burger Internet Draft - Expires 7/11/2000 [Page 19] Partial Non-Delivery Notification January 11, 2000 8.2. Confidentiality Another dimension of security is confidentiality. For example, a message recipient can be autoforwarding messages. However, she does not wish to divulge her autoforward address. The desire for such confidentiality will probably be heightened as "wireless mailboxes", such as pagers, become more widely used as autoforward addresses. Confidentiality also applies to the service provider. For example, in an Internet Voice Mail scenario, one can envision implementations of protocols such as VPIM [5] where reporting the actual Internet host name can open the system to attack. MTA authors are encouraged to provide a mechanism that enables the end user to preserve the confidentiality of a forwarding address. Depending on the degree of confidentiality required, and the nature of the environment to which a message were being forwarded, this might be accomplished by one or more of: (a) omitting the "Final-Recipient" field, as it has little use to the sender, (b) omitting "Remote-*" or extension fields of a PNDN whenever they would otherwise contain confidential information (such as a confidential forwarding address), (c) for messages forwarded to a confidential address, setting the envelope return address (e.g. SMTP MAIL FROM address) to the NULL reverse-path ("<>") (so that no PNDNs would be sent from a downstream MTA to the original sender), or (d) when forwarding mail to a confidential address, having the forwarding MTA rewrite the envelope return address for the forwarded message and attempt delivery of that message as if the forwarding MTA were the originator. On its receipt of final delivery status, the forwarding MTA would issue a PNDN to the original sender. In general, the Reporting MTA site can omit any optional PNDN field that it determines inclusion of the field would impose too great a compromise of site confidentiality. The need for such confidentiality must be balanced against the utility of the omitted information in trouble reports. Implementers are cautioned that many existing MTAs will send non- delivery notifications to a return address in the message header (rather than to the one in the envelope), in violation of SMTP and other protocols. If a message is forwarded through such an MTA, no Burger Internet Draft - Expires 7/11/2000 [Page 20] Partial Non-Delivery Notification January 11, 2000 reasonable action on the part of the forwarding MTA will prevent the downstream MTA from compromising the forwarding address. Likewise, if the recipient's MTA automatically responds to messages based on a request in the message header (such as the nonstandard, but widely used, Return-Receipt-To extension header), it will also compromise the forwarding address. 9. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Freed, N. and Borenstein, N, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft and First Virtual, November 1996. 3 Moore, K. and Vaudreuil, G., "An Extensible Message Format for Delivery Status Notifications", RFC 1894, U. Tennessee and Octel Network Services, January 1996. 4 a.k.a. VPIMv3 5 Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail - version 2", Lucent Technologies and Nortel Networks, RFC 2421, September 1998. 6 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7 Freed, N. and Borenstein, N, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and First Virtual, November 1996. 8 Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, National Institutes of Health, March 1998. 9 Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, Octel Network Services, January 1996. 10 Crocker, D. and Overell, P., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 11 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, Octel Network Systems, January 1996. Burger Internet Draft - Expires 7/11/2000 [Page 21] Partial Non-Delivery Notification January 11, 2000 10. Acknowledgments I'd like to thank Graham Klyne and Keith Moore for valuable insights into the mechanics of DSN. Graham Klyne also helped me put this document into English. However, any bizzare language is my own fault. Ned Freed and Herman R. Silbiger both had valuable experience corroborating the assertion that users do not like to receive failure notices unless there is a real failure. Carl-Uno Mauros was able to put into words much better than I did in a prior draft the differences between a system that cannot render a particular part versus a transmission failure. 11. Author's Address Eric W. Burger Centigram Communications Corporation Maryland Technology Center 1375 Piccard Dr., MS 150 R Rockville, MD 20850-4311 USA Phone: +1 301/212-3320 Email: e.burger@ieee.org Burger Internet Draft - Expires 7/11/2000 [Page 22] Partial Non-Delivery Notification January 11, 2000 12. Notices and Full Copyright Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Copyright (C) 1999, The Internet Society. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Burger Internet Draft - Expires 7/11/2000 [Page 23] From owner-ietf-fax@imc.org Thu Feb 17 10:59:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16388 for ; Thu, 17 Feb 2000 10:59:47 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA24571 for ietf-fax-bks; Thu, 17 Feb 2000 07:21:18 -0800 (PST) Received: from monsoon.mail.pipex.net (monsoon.mail.pipex.net [158.43.128.69]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA24567 for ; Thu, 17 Feb 2000 07:21:16 -0800 (PST) Received: (qmail 26213 invoked from network); 17 Feb 2000 14:55:11 -0000 Received: from userer48.uk.uudial.com (HELO GK-VAIO) (62.188.16.89) by smtp.dial.pipex.com with SMTP; 17 Feb 2000 14:55:11 -0000 Message-Id: <4.2.2.20000217142227.00acbea0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 17 Feb 2000 14:39:27 +0000 To: Eric.Burger@centigram.com From: Graham Klyne Subject: Re: draft-ema-vpim-pndn-00/01.txt Cc: owner-vpim@lists.neystadt.org, ietf-fax@imc.org In-Reply-To: <88256886.007E25AB.00@notes.centigram.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 02:55 PM 2/15/00 -0800, Eric.Burger@centigram.com wrote: >Document: draft-ema-vpim-pndn-01.txt February 15, >2000 > > Partial Non-Delivery Notification Eric, I thought this read very well. Even the bits I would have been inclined to disagree with, I found to be well-justified. I have a few minor comments. Firstly: a process matter: this was announced by the IETF as draft version -00? Is this really correct? Was the -00 version never published as an I-D? [Page 4:] > NOTE: An alternative method of handling partial delivery is to > determine what parts of the message the sender considers critical. "alternative" here seems to imply mutual exclusion. I would prefer, say, "An additional method ...". > If the voice mail system could not deliver the critical parts, then > the voice mail system would reject the entire message. If the voice > mail system could deliver the critical parts, but there were other > undeliverable parts, it would silently delete the parts from the > delivered message. The VPIM work group determined this method, in > practice, would be too complex to implement and would have the > drawback of the voice mail system silently deleting message > components. In light of the limitations of voice mail systems, we > decided to deliver as much of the message as possible, notifying the > sender of any parts that the voice mail system fails to deliver. You say "The VPIM work group determined ...". Is this true? I don't recall seeing this particular point discussed on the mailing list; did I miss someting? [...] >5.3.4. Original Content ID Field > > This field, if present in the original message, MUST be present in > the PNDN. It aids the sender in understanding exactly which body > part the receiving system is not capable of delivering. I think that the first sentence maybe should read: # The 'Original-content-id' field MUST be present in the PNDN if a 'Content-Id' # field is present in the original message. >5.3.5. Original Content Description Field > > This field, if present in the original message, MUST be present in > the PNDN. Similarly: "... if a 'Content-description' field is present in the original message." >5.3.6. Original Content Disposition Field > > This field, if present in the original message, MAY be present in > the PNDN if there is a Content Type field in the original message. Similarly: "... if a 'Content-disposition' field is present in the original message." >5.3.7. Original Content Type Field > > This field, if present in the original message, MUST be present in > the PNDN. Similarly: "... if a 'Content-type' field is present in the original message." >5.3.8. Status Field > [...] Define status values here (or put in placeholders for them)? (I think the approach of defining the status value(s) in the formal syntax is not so helpful.) -- Cheers, #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@imc.org Thu Feb 24 00:30:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11158 for ; Thu, 24 Feb 2000 00:30:57 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA16367 for ietf-fax-bks; Wed, 23 Feb 2000 19:59:34 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA16362 for ; Wed, 23 Feb 2000 19:59:32 -0800 (PST) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id NAA01982 for ; Thu, 24 Feb 2000 13:03:35 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id NAA02871 for ; Thu, 24 Feb 2000 13:03:34 +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 MAA08245 for ; Thu, 24 Feb 2000 12:59:38 +0900 (JST) To: ietf-fax@imc.org Subject: [FAX] New proposed charter X-Mailer: Mew version 1.94.1 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: <20000224130654H.tamura@toda.ricoh.co.jp> Date: Thu, 24 Feb 2000 13:06:54 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 125 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Colleagues, I am Hiroshi Tamura. I've become a co-chair of Fax extensions wg. Unfortunately, Mr. Rafferty cannot continue to be a chair. But, thanks to his great chairmanship, We achieived lots of things. (Of course, including the people in this wg). Anyway, Following is the proposed charter in this wg. Any comments are appreciated. ####################################################### Proposed Charter: ================ Internet Fax Extensions (faxext) -------------------------------- Chair(s): Hiroshi Tamura One more person anticipated <> Applications Area Director(s): Keith Moore Patrik Faltstrom Area Advisor ? Mailing lists: General Discussion:ietf-fax@imc.org To Subscribe: ietf-fax-request@imc.org In Body: In Body: subscribe Archive: http://www.imc.org/ietf-fax/ DESCRIPTION OF WORKING GROUP: Previous IETF efforts developed specifications for simple and extended Internet mail-based facsimile service profiles, tailored to interwork with the world of T.30 facsimile. This extension effort will produce a final increment of specification for supporting a "full" equivalence of T.30 service over Internet mail. Technical work for this effort includes timely delivery, [image] feature selection/negotiation, document privacy, and integrated specification of Full-mode Facsimile Profile of Internet Mail (FFPIM). Differential routing between classic Internet mail and timely deliveries will be considered, as will universal messaging issues. For interconnecting fax services over the dial-up telephone network and carriage of facsimile message data over the Internet, two types of interface systems are required: o Internet/Dial-up Fax gateway, moving data from the Internet to classic or Internet-aware dial-up fax products and services o Dial-up/Internet Fax gateway, moving data from classic or Internet-aware dial-up fax products and services to the Internet The working group will also consider the requirements for gatewaying Internet Mail (as profiled for facsimile Simple, Extended modes and FFPIM) with T.30 Facsimile. The working group will specifically take note of quality of service issues and might decide to produce an Implementer's Guide. T.30 facsimile carries expectations of message privacy, so that FFPIM must specify a basic facility via the Internet. Although T.30 does not provide document authentication, users frequently believe that it does. Consequently the Faxext working group will also seek specification of a basic authentication facility over the Internet. T.30 facsimile provides for receiver capability identification to the sender, allowing a sender to provide the "best" fax image the receiver can handle. The Faxext working group will consider mechanisms to provide similar functionality for fax images transferred by e-mail. Additional areas of discussion will be: Annotated fax messages and universal messaging issues as they relate to FFPIM, as well as schema and TIFF extensions required to support the new JBIG-2 (T.88) compression method. The working group will continue the excellent pattern of coordinating activities with other facsimile-related standards bodies, in particular the ITU, and with using work from related IETF efforts. GOALS AND MILESTONES: Mar 2000 Working Group chartered Mar 2000 Initial drafts for timely delivery , content negotiaton and FFPIM Mar 2000 Initial draft of Implementors Guide for Simple and Extended mode Jun 2000 Revised drafts for timely delivery, content negotiaton and FFPIM Jul 2000 Initial Routing considerations draft Jul 2000 Initial draft of gateway requirements Jul 2000 Final draft of Implementors Guide for Simple and Extended mode Sep 2000 Initial drafts of schema and TIFF-fx extensions for JBIG-2 Nov 2000 Final draft for timely delivery and content negotiaton. Nov 2000 Final draft of Routing Considerations Nov 2000 Final draft of FFPIM Mar 2001 Final draft of gateway requirements Apr 2001 Final drafts of schema and TIFF-fx extensions for JBIG-2 ####################################################### -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@imc.org Fri Feb 25 19:59:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23825 for ; Fri, 25 Feb 2000 19:59:38 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA05839 for ietf-fax-bks; Fri, 25 Feb 2000 16:17:43 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA05835 for ; Fri, 25 Feb 2000 16:17:42 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA13066; Fri, 25 Feb 2000 16:20:58 -0800 (PST) Date: Fri, 25 Feb 2000 16:20:58 -0800 (PST) From: Dan Wing To: Hiroshi Tamura cc: ietf-fax@imc.org Subject: Re: [FAX] New proposed charter In-Reply-To: <20000224130654H.tamura@toda.ricoh.co.jp> Message-ID: <0002251617530.1011-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 24 Feb 2000 13:06 +0900, Hiroshi Tamura wrote: > Dear Colleagues, > > I am Hiroshi Tamura. I've become a co-chair of Fax extensions wg. Great! > Unfortunately, Mr. Rafferty cannot continue to be a chair. > But, thanks to his great chairmanship, We achieived lots of things. > (Of course, including the people in this wg). > > Anyway, > Following is the proposed charter in this wg. > Any comments are appreciated. The charter looks good (and well-worded, I might add). However, what is FFPIM? It is referenced in the charter but it isn't defined. > GOALS AND MILESTONES: > > Mar 2000 Working Group chartered > > Mar 2000 Initial drafts for timely delivery , content negotiaton > and FFPIM > > Mar 2000 Initial draft of Implementors Guide for Simple and > Extended mode > > Jun 2000 Revised drafts for timely delivery, content negotiaton > and FFPIM > > Jul 2000 Initial Routing considerations draft > > Jul 2000 Initial draft of gateway requirements March 2000 is quickly approaching. Have authors volunteered to write the above "Initial drafts"? I would recommend that the list of three initial drafts be separated into three distinct line items, like the Implementors Guide: Mar 2000 Initial draft for timely delivery Mar 2000 Initial draft for content negotiaton for fax Mar 2000 Initial draft for FFPIM Mar 2000 Initial draft of Implementors Guide for Simple and Extended mode -Dan Wing From owner-ietf-fax@imc.org Sun Feb 27 18:37:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12857 for ; Sun, 27 Feb 2000 18:37:16 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA18055 for ietf-fax-bks; Sun, 27 Feb 2000 15:06:36 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA18048 for ; Sun, 27 Feb 2000 15:06:31 -0800 (PST) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id IAA20140; Mon, 28 Feb 2000 08:06:12 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id IAA22774; Mon, 28 Feb 2000 08:06:11 +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 IAA08500; Mon, 28 Feb 2000 08:02:08 +0900 (JST) To: dwing@cisco.com Cc: ietf-fax@imc.org Subject: Re: [FAX] New proposed charter In-Reply-To: <0002251617530.1011-100000@omega.cisco.com> References: <20000224130654H.tamura@toda.ricoh.co.jp> <0002251617530.1011-100000@omega.cisco.com> X-Mailer: Mew version 1.94.1 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: <20000228080937N.tamura@toda.ricoh.co.jp> Date: Mon, 28 Feb 2000 08:09:37 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 36 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Wing-san, Thank you for your comments. > However, what is FFPIM? It is referenced in the charter but it isn't > defined. Although you know it, but, to make sure, "Full-mode Fax Profile for Internet Mail: FFPIM" from "draft-ietf-fax-ffpim-00.txt" > > Mar 2000 Initial draft of Implementors Guide for Simple and > > Extended mode This may not be "Initial", but "Revised". "Initial" is "draft-ietf-fax-implementers-guide-00.txt" But "Initial" may be better, even now. Modifications will be made for it. > Mar 2000 Initial draft for timely delivery > > Mar 2000 Initial draft for content negotiaton for fax > > Mar 2000 Initial draft for FFPIM > > Mar 2000 Initial draft of Implementors Guide for Simple and > Extended mode OK. No problems for me. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@imc.org Tue Feb 29 01:07:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00443 for ; Tue, 29 Feb 2000 01:07:08 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA09850 for ietf-fax-bks; Mon, 28 Feb 2000 21:32:34 -0800 (PST) Received: from gw3.octel.com (gw3.octel.com [206.189.47.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA09846 for ; Mon, 28 Feb 2000 21:32:33 -0800 (PST) Received: from curly.eng.octel.com (curly.eng.octel.com [148.147.200.26]) by gw3.octel.com (8.9.3/8.9.3) with ESMTP id VAA13449; Mon, 28 Feb 2000 21:32:25 -0800 (PST) Received: from buzz.ons.octel.com (buzz.ons.octel.com [155.184.13.4]) by curly.eng.octel.com (8.9.3/8.9.3) with ESMTP id VAA08262; Mon, 28 Feb 2000 21:32:24 -0800 (PST) Received: from exdal1.ons.octel.com (exdal1 [155.184.13.201]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id XAA16233; Mon, 28 Feb 2000 23:32:22 -0600 (CST) Received: by exdal1.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 28 Feb 2000 23:40:34 -0600 Message-ID: <6B57F36F4FF9D111B30A0008C7F4133702E4DB4C@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: IETF VPIM List , IETF fax WG Subject: Binary ESMTP experience wanted! Date: Mon, 28 Feb 2000 23:40:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, It is time to promote RFC 1830, " SMTP Service Extensions for Transmission of Large and Binary MIME Messages" to the status of proposed standard within the IETF. RFC1830 is currently an experimental protocol believed to be very useful for the transmission of audio and graphical data. If you have implemented this protocol and/or interoperability tested heterogeneous systems using this protocol in either product or prototype code, please drop me a short note. Thank you. Greg Vaudreuil From owner-ietf-fax@imc.org Tue Feb 29 05:09:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14183 for ; Tue, 29 Feb 2000 05:09:06 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA22323 for ietf-fax-bks; Tue, 29 Feb 2000 01:48:16 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA22319 for ; Tue, 29 Feb 2000 01:48:14 -0800 (PST) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id SAA14770 for ; Tue, 29 Feb 2000 18:48:14 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id SAA17969 for ; Tue, 29 Feb 2000 18:48:14 +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 SAA08780 for ; Tue, 29 Feb 2000 18:44:08 +0900 (JST) To: ietf-fax@imc.org Subject: [FAX] Proposed charter and Agenda in Adelaide X-Mailer: Mew version 1.94.1 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: <20000229185142K.tamura@toda.ricoh.co.jp> Date: Tue, 29 Feb 2000 18:51:42 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 30 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Colleagues, Does anyone have any suggestions about the charter ? If not, I fix it and send it to ADs. And, From IETF page, we have a slot in Thursday morning. We have the following itemss for discussion. - draft for timely delivery - draft for content negotiaton for fax - draft for FFPIM - draft of Implementors Guide Any other discussion items ? McIntyre-san, How about TIFF-FX extension for JBIG2 ? Does anyone have Gateway issues, which we have to discuss in Adelaide ? If you have requests or something, please mail to me soon. -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@imc.org Tue Feb 29 16:41:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03164 for ; Tue, 29 Feb 2000 16:41:23 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA17188 for ietf-fax-bks; Tue, 29 Feb 2000 13:02:10 -0800 (PST) Received: from Brooktrout.Com (truite.brooktrout.com [204.176.74.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17180 for ; Tue, 29 Feb 2000 13:02:07 -0800 (PST) Received: from nhmail1.admin.brooktrout.com (nhmail1.admin.brooktrout.com [204.176.75.8]) by Brooktrout.Com (8.9.3/8.9.3/BTI-2.1) with ESMTP id PAA12145; Tue, 29 Feb 2000 15:50:19 -0500 Message-Id: <200002292050.PAA12145@Brooktrout.Com> Received: from jraff.brooktrout.com (dhcp24.sales.brooktrout.com [204.176.75.171]) by nhmail1.admin.brooktrout.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1W13CZ5B; Tue, 29 Feb 2000 15:51:58 -0500 X-Sender: jrafferty@humancomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 29 Feb 2000 15:52:36 -0500 To: Hiroshi Tamura , ietf-fax@imc.org From: James Rafferty Subject: Re: [FAX] New proposed charter In-Reply-To: <20000224130654H.tamura@toda.ricoh.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:06 PM 2/24/00 +0900, Hiroshi Tamura wrote: >Dear Colleagues, > >I am Hiroshi Tamura. I've become a co-chair of Fax extensions wg. > >Unfortunately, Mr. Rafferty cannot continue to be a chair. >But, thanks to his great chairmanship, We achieived lots of things. >(Of course, including the people in this wg). > To clarify, Patrik has asked me to stay on board as co-chair to assist Tamura-san, until the selection of the other co-chair is finalized. I still have a couple of cleanup items on existing WG business. The new co-chairs will be handling the new issues, such as the re-chartering . James