From owner-ietf-fax@imc.org Thu Jan 6 07:14:27 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 HAA07872 for ; Thu, 6 Jan 2000 07:14:27 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA05246 for ietf-fax-bks; Thu, 6 Jan 2000 03:40:05 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05242 for ; Thu, 6 Jan 2000 03:40:04 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07044; Thu, 6 Jan 2000 06:40:11 -0500 (EST) Message-Id: <200001061140.GAA07044@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-fax@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-fax-feature-schema-v2-01.txt Date: Thu, 06 Jan 2000 06:40:10 -0500 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Fax Working Group of the IETF. Title : Content Feature Schema for Internet Fax Author(s) : G. Klyne, L. McIntyre Filename : draft-ietf-fax-feature-schema-v2-01.txt Pages : 67 Date : 05-Jan-00 This document revises the content feature schema described in RFC 2531, with clarifications to some of the feature tag descriptions and addition of one new feature tag. This content feature schema is a profile of the media feature description mechanisms [1,2,3] for use in performing capability exchange between extended Internet fax systems [5]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-feature-schema-v2-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fax-feature-schema-v2-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-fax-feature-schema-v2-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000105082623.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-feature-schema-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-feature-schema-v2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000105082623.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@imc.org Thu Jan 6 07:14: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 HAA07883 for ; Thu, 6 Jan 2000 07:14:29 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA05252 for ietf-fax-bks; Thu, 6 Jan 2000 03:40:10 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05248 for ; Thu, 6 Jan 2000 03:40:09 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07058; Thu, 6 Jan 2000 06:40:16 -0500 (EST) Message-Id: <200001061140.GAA07058@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-fax@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-fax-feature-T30-mapping-03.txt Date: Thu, 06 Jan 2000 06:40:16 -0500 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Fax Working Group of the IETF. Title : Internet fax T.30 Feature Mapping Author(s) : L. McIntyre, G. Klyne Filename : draft-ietf-fax-feature-T30-mapping-03.txt Pages : 39 Date : 05-Jan-00 This document describes how to map Group 3 fax capability identification bits, described in ITU T.30 [6], into the Internet fax feature schema described in 'Content feature schema for Internet fax' [4]. This is a companion to the fax feature schema document [4], which itself defines a profile of the media feature registration mechanisms [1,2,3], for use in performing capability identification between extended Internet fax systems [5]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-feature-T30-mapping-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fax-feature-T30-mapping-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-fax-feature-T30-mapping-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000105082634.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-feature-T30-mapping-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-feature-T30-mapping-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000105082634.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@imc.org Thu Jan 6 14:47:59 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 OAA20957 for ; Thu, 6 Jan 2000 14:47:56 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA12776 for ietf-fax-bks; Thu, 6 Jan 2000 10:49:52 -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 KAA12771 for ; Thu, 6 Jan 2000 10:49:50 -0800 (PST) Received: (qmail 688 invoked from network); 6 Jan 2000 18:49:52 -0000 Received: from userau49.uk.uudial.com (HELO gk-vaio) (62.188.137.251) by smtp.dial.pipex.com with SMTP; 6 Jan 2000 18:49:52 -0000 Message-Id: <4.2.2.20000106180151.00a3d540@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 06 Jan 2000 18:47:37 +0000 To: Eric.Burger@centigram.com From: Graham Klyne Subject: draft-ema-vpim-pndn-00.txt Cc: IETF fax WG , IETF VPIM List 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: I've finally got around to reviewing the partial NDN draft, and have a few comments for your consideration... My biggest single question with this draft is that it uses a new report type, rather than just extending the DSN report format (which is, after all, an extensible format). I fear the consequence of this may be that interoperability between voicemail systems (and any other systems that implement PNDN) and traditional e-mail systems may be harmed. Specifically, what is a traditional e-mail agent to make of a response message of the form: Content-type: multipart/report;report-type=partial-delivery-status I think it would be much easier to achieve clean interoperability with existing e-mail systems if the existing DSN report format were to be used, with extension fields (as permitted by the DSN spec) used to convey the additional information about partial delivery, but which can be ignored by sending systems that have no concept of partial delivery, but which may still usefully receive some indication of successful delivery. I recognize this approach raises some questions and challenges. Some are: - for a sender that does not recognize partial delivery, should this condition be prresented as "delivered" or some other status? - how to handle multiple recipients without causing unreasonable growth in the size of the status report? (I think that the idea of eliding multiple recipients into a single "per-recipient" part might be a useful extension to the DSN report form, but if that causes compatibility problems then it's not really an option.) - resolving privacy concerns regarding recipient fields. The rest of my comments are mostly nits and presentational issues related to specific parts of tyhe text, as noted below... >3. > Introduction [...] > This Internet draft addresses the need to allow desktop e-mail > client applications to send arbitrary multi-part multimedia messages > to voice messaging systems, retaining the semantics of delivery > notification, taking into account the limitations of the voice > messaging system rendering limitations. The method described by > this Internet draft 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 RFC. However, many voice mail systems are not > capable of making this notification. References above to "this Internet draft" and "this RFC" -- I suggest are changed to "this document" > NOTE: An alternative method of handling partial delivery is to > determine what parts of the message the sender considers to be > 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 parts the voice mail system could not deliver, 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. While I do not disagree with this assessment, I'd also note that it does not completely eliminate the possible use of a "critical content" indicator -- with the intent that if indicated critical content cannot be delivered then nothing should be delivered. (In the absence of such indication, no part being regarded as critical.) >4. > Operation [...] > If the recipient system is capable of only delivering part(s) of the Nit: "only delivering part(s) ..." --> "delivering only part ..." > message, it will return a partial non-delivery notification (PNDN) > as described below. [...] > 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 a Nit: insert "than" after "MTA" > 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. While I do not disagree with this assessment, I'd also note that there is still possible use for a partial processing indication (especially in the context of Internet fax, where I understand that per-page processing indications are perceived by some to be useful). I think it would be good if the mechanisms introduced could be easily adapted to MDNs as well as DSNs >5. > Contents of the PNDN [...] >5.1. The message/partial-delivery-status content-type As already indicated, my preference would be for introducing this functionality as an extension to message/delivery-status, rather than a new report type. [...] > The body of a message/partial-delivery-status consists of one or > more "fields" formatted according to the ABNF [10]. Nit: RFC2234 [10] does not define "fields". Irt defines a notation for describing fields. The field formats are described in [DSN] and later in this document. [...] >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 > 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. Partly because I would prefer extension to the DSN format, I also think it would be better to develop from the DSN concept of "per-recipient" fields, possibly having "per-recipient+part" fields. I would view collapsing these into a single group when the same information applies to more than one recipient as a possibly useful optimization. In any case, I think the text here should be clearer about the handling of responses dealing with multiple recipients and multiple message parts. >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 is "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]. I was thinking that it would be nice if the concept of partial delivery could be noted in the "action" field. But it seems that this is not an extensible value set per [DSN], so I guess that's not an option. >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 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. Why is this not an issue with traditional e-mail? Also, why is the "original-recipient" field only optional for DSN, while final-recipient is mandatory? >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/TELECNNCT.COM" Report type inconsistent? (Similarly for examples in sections 6.2, 6.3, 6.4) > --RAA14128.773615765/TELECNNCT.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@telecnnct.com > > Body part will be deleted from queue > > --RAA14128.773615765/TELECNNCT.COM > content-type: message/partial-delivery-status [...] >7. > Formal Syntax [...] > original-content-id-field = > "Original-Content-ID" ":" content-id > > original-content-description-field = > "Original-Content-Description" ":" content-description > > original-content-disposition-field = > "Original-Content-Disposition" ":" content-disposition > > original-content-type-field = > "Original-Content-Type" ":" content-type Where are the syntax terms content-id, content-description, content-disposition and content-type defined? --- That's my lot. Thanks for your efforts in preparing this. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@imc.org Thu Jan 6 16:33:32 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 QAA22782 for ; Thu, 6 Jan 2000 16:33:28 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA14347 for ietf-fax-bks; Thu, 6 Jan 2000 13:03:21 -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 NAA14342 for ; Thu, 6 Jan 2000 13:03:19 -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 QAA01129; Thu, 6 Jan 2000 16:01:23 -0500 (EST) Message-Id: <200001062101.QAA01129@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Graham Klyne cc: Eric.Burger@centigram.com, IETF fax WG , IETF VPIM List Subject: Re: [VPIM] draft-ema-vpim-pndn-00.txt In-reply-to: Your message of "Thu, 06 Jan 2000 18:47:37 GMT." <4.2.2.20000106180151.00a3d540@pop.dial.pipex.com> Date: Thu, 06 Jan 2000 16:01:23 -0500 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: offhand, I believe the best indication of partial delivery would be a nondelivery report (DSN with failure status) with an appropriate status code indicating inability to decode the message or some such. It could have additional fields explaining which pages were printed etc. that way, a system that didn't understand partial delivery would see a delivery failure notice and perhaps notify the sender of the failure (along with the error message indicating partial failure); while one that did understand partial delivery could examine the additional fields. this seems to me better than having a separate kind of delivery report for partial delivery. Keith From owner-ietf-fax@imc.org Thu Jan 6 20:37: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 UAA26524 for ; Thu, 6 Jan 2000 20:37:09 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA16980 for ietf-fax-bks; Thu, 6 Jan 2000 17:09:09 -0800 (PST) Received: from mtiwmhc01.worldnet.att.net (mtiwmhc01.worldnet.att.net [204.127.131.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA16976 for ; Thu, 6 Jan 2000 17:09:07 -0800 (PST) Received: from none ([12.78.198.142]) by mtiwmhc01.worldnet.att.net (InterMail v03.02.07.07 118-134) with SMTP id <20000107010842.JWLO5516@none>; Fri, 7 Jan 2000 01:08:42 +0000 Message-Id: X-Sender: JRafferty@postoffice.worldnet.att.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 06 Jan 2000 11:17:05 -0500 To: Keith Moore , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , ietf-secretariat From: James Rafferty Subject: [Fax] Internet Fax Working Group - Request for IESG Consideration Cc: Ietf-Fax , TSG8IFAX 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: The Internet Fax Working Group requests IESG approval for publication of the following documents, with the specified status. DOCUMENT: Content feature schema for Internet fax draft-ietf-fax-feature-schema-V2-01.txt Status: Proposed Standard Technical Summary: This document is a revision to RFC 2531 and updates the definition of the content feature schema for Internet fax. Upon approval, it will obsolete RFC 2531. The document is being proposed for recycling at the Proposed Standard level, because technical changes have been made to one key schema tag having to do with image structures. It is felt that the updated definition provides more clarity on distinctions between the possible TIFF image structures. Other small editorial revisions have also been made, but the content on a whole is not changed much from RFC 2531. The draft has completed an Internet Fax working group Last Call and only small editorial changes were needed during this period. DOCUMENT: Internet fax T.30 Feature Mapping draft-ietf-fax-feature-t30-mapping-03.txt Status: Informational Technical Summary: The T.30 Mapping document is a companion document for the fax feature schema. It takes the fax feature content tags which are defined in RFC 2531 (and the proposed replacement for this document) and explains how these can be mapped to the way that features are represented in the T.30 Group 3 fax protocol that is used for phone line based communications. Thus, this document will help implementors to be able to represent a common feature set for use in either Group 3 fax or extended Internet fax communications. This document has been under development for over a year and has undergone extensive review in both the WG and in the ITU Study Group 8. It has completed a WG Last call and only minor editorial revisions were made during this time. James Rafferty Chair, IETF Internet Fax WG *------------------------------------------------* James Rafferty President, Human Communications LLC 12 Kevin Drive Danbury, CT 06811-2901 USA Voice/Fax: +1-203-746-4367 Fax to email: +1-603-925-5753 (Current Preferred Fax Number) Email/Internet Fax: JRafferty@worldnet.att.net Alternate email : jrafferty@humancomm.com, j_rafferty_hc@compuserve.com (chg from csi.com) HC Web Site: http://humancomm.com *--------------------------------------------------- From owner-ietf-fax@imc.org Thu Jan 6 20:37:25 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 UAA26535 for ; Thu, 6 Jan 2000 20:37:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA16987 for ietf-fax-bks; Thu, 6 Jan 2000 17:09:20 -0800 (PST) Received: from mtiwmhc01.worldnet.att.net (mtiwmhc01.worldnet.att.net [204.127.131.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA16983 for ; Thu, 6 Jan 2000 17:09:19 -0800 (PST) Received: from none ([12.78.198.142]) by mtiwmhc01.worldnet.att.net (InterMail v03.02.07.07 118-134) with SMTP id <20000107010855.JWNP5516@none> for ; Fri, 7 Jan 2000 01:08:55 +0000 Message-Id: X-Sender: JRafferty@postoffice.worldnet.att.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 06 Jan 2000 11:17:26 -0500 To: Ietf-Fax From: James Rafferty Subject: [fax] WG Last Call Report - Fax Feature Schema and T.30 Mapping 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: Folks, Now that the holidays are over, some outstanding items can be addressed. The following 2 documents were submitted for Internet Fax WG Last Call on November 22, 1999: draft-ietf-fax-feature-schema-V2-00.txt - Content feature schema for Internet fax draft-ietf-fax-feature-t30-mapping-02.txt - Internet fax T.30 Feature Mapping During the last call period, some minor editorial revisions were made by the authors, but no other comments were received. Both of these documents have received considerable review prior to the WG Last Call. The updated drafts are: draft-ietf-fax-feature-schema-V2-01.txt draft-ietf-fax-feature-t30-mapping-03.txt Therefore, I will be submitting both documents to the IESG. The fax feature schema document is proposed as a replacement for RFC 2531, so it will be submitted for consideration as a proposed standard. It contains technical changes from RFC 2531. This is the reason I plan to request recycling to proposed standard status. The T.30 mapping document will be proposed for publication as an informational RFC. Thanks to all who have commented on these documents. James *------------------------------------------------* James Rafferty President, Human Communications LLC 12 Kevin Drive Danbury, CT 06811-2901 USA Voice/Fax: +1-203-746-4367 Fax to email: +1-603-925-5753 (Current Preferred Fax Number) Email/Internet Fax: JRafferty@worldnet.att.net Alternate email : jrafferty@humancomm.com, j_rafferty_hc@compuserve.com (chg from csi.com) HC Web Site: http://humancomm.com *--------------------------------------------------- From owner-ietf-fax@imc.org Fri Jan 7 12:43: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 MAA23955 for ; Fri, 7 Jan 2000 12:43:39 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA10120 for ietf-fax-bks; Fri, 7 Jan 2000 09:02:20 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10116 for ; Fri, 7 Jan 2000 09:02:19 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22609; Fri, 7 Jan 2000 12:02:26 -0500 (EST) Message-Id: <200001071702.MAA22609@ietf.org> To: IETF-Announce: ; Cc: ietf-fax@imc.org From: The IESG SUBJECT: Last Call: Content feature schema for Internet fax to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 07 Jan 2000 12:02:26 -0500 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Internet Fax Working Group to consider: o Content feature schema for Internet fax as a Proposed Standard. o Internet fax T.30 Feature Mapping as Informational. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 21, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fax-feature-schema-v2-01.txt http://www.ietf.org/internet-drafts/draft-ietf-fax-feature-T30-mapping-03.txt From owner-ietf-fax@imc.org Sat Jan 8 07:09:49 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 HAA17920 for ; Sat, 8 Jan 2000 07:09:48 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA09482 for ietf-fax-bks; Sat, 8 Jan 2000 03:48:46 -0800 (PST) Received: from energy.ogu.edu.tr (root@energy.ogu.edu.tr [193.140.141.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA09475; Sat, 8 Jan 2000 03:48:40 -0800 (PST) From: blilrel16@aol.com Received: from energy.ogu.edu.tr (98C9FD37.ipt.aol.com [152.201.253.55]) by energy.ogu.edu.tr (8.8.8/8.8.4) with SMTP id NAA03399; Sat, 8 Jan 2000 13:42:37 +0200 Date: Sat, 08 Jan 00 01:43:26 EST To: Friend@public.com Subject: A Search Engine Just For You ! Message-ID: <> Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This e-mail is to inform you of a new search engine for adult web sites: http://www.adultfairlinks.com. Fairlinks is being built at this time and will be launched in a few months. We are contacting webmasters now so you can take a look at the site and give us any input you may have. This site will be unique since it will be a TRUE SEARCH ENGINE FOR ADULT SITES. There will be no banner ads, no support from any adult site. All categories will rotate so that each site will be at the top. Two thirds of all money collected will then be used to promote Fairlinks. Most advertising will be done off the web with plans already made to market the site on the Internet. We are going to pool thousands of adult sites together to form a partnership that will make a formidable force and to have funds for national advertising. Please take a look, join in and get your site promoted as it should be! http://www.adultfairlinks.com To be removed, call (888) 341-4786 and Clearly spell your email address and you will be removed. From owner-ietf-fax@imc.org Wed Jan 12 03:07:14 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 DAA10860 for ; Wed, 12 Jan 2000 03:07:13 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA29668 for ietf-fax-bks; Tue, 11 Jan 2000 23:30:18 -0800 (PST) Received: from mis2.centigram.com (pix70.centigram.com [198.137.183.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA29656 for ; Tue, 11 Jan 2000 23:30:13 -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 XAA00374; Tue, 11 Jan 2000 23:29:33 -0800 (PST) Received: by notes.centigram.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 88256864.0029499F ; Tue, 11 Jan 2000 23:30:58 -0800 X-Lotus-FromDomain: CENTIGRAM To: gk@acm.org, moore@cs.utk.edu cc: IETF fax WG , IETF VPIM List , vpim-l@listmail.ema.org Message-ID: <88256864.002947FA.00@notes.centigram.com> Date: Tue, 11 Jan 2000 18:23:04 -0500 Subject: Re: draft-ema-vpim-pndn-00.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: Thanks Graham and Keith for your comments. You both hit on what was the hardest part for me to work out. I dithered back and forth, about whether partial-delivery was a special case of DSN or something else. In fact, my first write-up was simply an extension of DSN. I'm not wed to it being something new. In fact, one of the reasons I tried to make partial-delivery an extension of DSN is that I expect a simple extension would have a much easier time of getting IETF approval than a new message type. The big hint that PNDN's are an extension of DSN is that 70% of the PNDN draft is cut-and-paste from DSN (including the ABNF bug -- good catch Graham!). However, the following issue made me fall into the camp that PNDN's are something different. DSN's deal with whole messages only. There is no mechanism for identifying parts of a message that fail yet having other parts being delivered. Either the system delivered the message or it didn't. If a sending system has a human reading the DSN, then we have some flexibility with extending DSN. However, we could have a sending system that parses the DSN. However, it doesn't understand the difference between an RFC 1894 DSN (whole message failed) and a PNDN (part of the message succeeded). In this case, aren't we in the same situation as a system that doesn't understand PNDN? Keith, I'll defer to you as the DSN expert. Is there an easy way of extending DSN without breaking it? Graham: I've incorporated all of your "nits". Thanks for the close reading. The only thing I saw that was up for discussion is the change of final-recipient from MUST to MAY. I think (again, I'll defer to Keith, since he was there) that final-recipient was mandatory because making it available would greatly help the sender determine if the failure was an addressing error. My position on this is the security issue of hiding telco resources is more important (and more likely) than the end user debugging MX records. If you think I'm being too paranoid, I can take out this provision. Otherwise, I can put in a NOTE describing why I made the change. Thanks again for your review. -- - Eric From owner-ietf-fax@imc.org Wed Jan 12 08:45:38 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 IAA15759 for ; Wed, 12 Jan 2000 08:45:37 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA15094 for ietf-fax-bks; Wed, 12 Jan 2000 05:19:34 -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 FAA15090 for ; Wed, 12 Jan 2000 05:19:32 -0800 (PST) Received: (qmail 22236 invoked from network); 12 Jan 2000 13:19:59 -0000 Received: from usero988.uk.uudial.com (HELO gk-vaio) (193.149.90.242) by smtp.dial.pipex.com with SMTP; 12 Jan 2000 13:19:59 -0000 Message-Id: <4.2.2.20000112103753.00a38de0@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 12 Jan 2000 10:43:01 +0000 To: Eric.Burger@centigram.com From: Graham Klyne Subject: Re: draft-ema-vpim-pndn-00.txt Cc: moore@cs.utk.edu, IETF fax WG , IETF VPIM List , vpim-l@listmail.ema.org In-Reply-To: <88256864.002947FA.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 06:23 PM 1/11/00 -0500, Eric.Burger@centigram.com wrote: >However, the following issue made me fall into the camp that PNDN's are >something different. DSN's deal with whole messages only. There is no >mechanism for identifying parts of a message that fail yet having other >parts being delivered. Either the system delivered the message or it >didn't. Indeed. And if the mechanism to be backwards compatible (with DSN), I believe this issue needs to be tackled head on. Current DSN 'clients' will be able to recognize only 'delivered' or 'not-delivered' outcomes. I think the key question, then, is: does partial delivery constitute a 'delivered' outcome or a 'not-delivered' outcome? I believe a DSN response should reflect the outcome of this decision (for the benefit of current DSN clients), and then use additional DSN extension fields (ignored by current clients) to provide more detailed information for the benefit of PNDN clients. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@imc.org Wed Jan 12 09:20:04 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 JAA16607 for ; Wed, 12 Jan 2000 09:20:03 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA15402 for ietf-fax-bks; Wed, 12 Jan 2000 05:49:23 -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 FAA15397 for ; Wed, 12 Jan 2000 05:49:22 -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 IAA28117; Wed, 12 Jan 2000 08:47:01 -0500 (EST) Message-Id: <200001121347.IAA28117@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Eric.Burger@centigram.com cc: gk@acm.org, moore@cs.utk.edu, IETF fax WG , IETF VPIM List , vpim-l@listmail.ema.org Subject: Re: draft-ema-vpim-pndn-00.txt In-reply-to: Your message of "Tue, 11 Jan 2000 18:23:04 EST." <88256864.002947FA.00@notes.centigram.com> Date: Wed, 12 Jan 2000 08:47:00 -0500 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > However, we could have a sending system > that parses the DSN. However, it doesn't understand the difference between > an RFC 1894 DSN (whole message failed) and a PNDN (part of the message > succeeded). In this case, aren't we in the same situation as a system that > doesn't understand PNDN? For a sender that understands DSN but doesn't understand PNDN, I think the choice is one of the following: - sender understands that there was some sort of message delivery problem, and perhaps chooses to resend the entire message. - sender doesn't understand that there was a message delivery problem because he/she/it doesn't know how to parse the PNDN at all. To me, the first choice sounds like the safer and more conservative one. In general, anytime a delivery agent cannot deliver a message with complete fidelity it has a choice - should this be reported as "partial delivery" (thus a form of success) or delivery failure? There are lots of potential cases that could be labelled partial delivery - such as when the main portion of the message can be delivered but some attachments cannot, or when all parts can be transferred but there is likely to be some conversion loss (say when a color image gets gatewayed via black-and-white fax), or when some but not all pages of a fax can be delivered. The choice of whether to label such an event (partial) success or failure seems like one which should be very dependent on the specific circumstances of the the message and its delivery or conversion. Of course it would help to have some guidance from the standards on when to label something a success and when to label it a failure. We grappled with this to some degree while working on DSNs, which is why there are status codes for both 'conversion required but not supported' (presumably a failure) and 'conversion with loss performed' (presumably a success). Also, I think it would be odd for us to use DSN to report delivery failure, and also to use DSN to report complete delivery success, but to use some other format for reporting partial success. Seems like it is cleaner to use DSN for everything, to choose a 2.x.x. or 4.x.x or 5.x.x status code as appropriate for the overall message (new status codes could be defined for fax), and to add additional fields to the DSN to provide more detail about which parts of the message were undeliverable. Keith From owner-ietf-fax@imc.org Fri Jan 14 10:47:13 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 KAA18602 for ; Fri, 14 Jan 2000 10:47:10 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA29281 for ietf-fax-bks; Fri, 14 Jan 2000 06:23:56 -0800 (PST) Received: from cybergateway.net ([206.104.28.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA29253; Fri, 14 Jan 2000 06:21:32 -0800 (PST) From: becky2421@aol.com Received: from 206.104.28.14 [152.172.118.203] by cybergateway.net (SMTPD32-5.01) id A4879CD01FE; Fri, 14 Jan 2000 08:55:35 +0100 Received: from jason@gulfcoast.net by jason@gulfcoast.net (8.8.5/8.6.5) with SMTP id GAA07984 for < jason@gulfcoast.net>; Fri, 14 Jan 2000 07:38:29 -0600 (EST) Date: Fri, 14 Jan 00 07:38:29 EST To: jason@gulfcoast.net Subject: New USA and International Merchant Accounts Message-ID: <> Reply-To: jason@gulfcoast.net Comments: Authenticated sender is < jason@gulfcoast.net> Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW U.S.A. and INTERNATIONAL MERCHANT ACCOUNTS FOR THE WORLD. Click below to Apply http://hypermart.com@3462929566/%63ar%64%73%65%72%76%69%63%65/%64%65%66%61u%6C%74%2Eh%74%6D#@3626198025/%63%61%72d%73%65%72%76%69%63%65/d%65fa%75%6C%74%2E%68%74%6D#@3462929566/ca%72d%73%65%72%76%69%63%65%32/%69%6E%64%65%78%2E%68%74%6D@3491382728/%63a%72d%73e%72%76%69%63%65/%64e%66%61%75%6C%74%2E%68t%6D ARE YOU REALLY AN E-COMMERCE MERCHANT? Increase your revenues by up to 1500% by accepting credit cards and electronic checks. Increase your customer base 200- 400% with instant access to the World. ARE YOU PAYING TOO MUCH? Discount rates start at 2.1% Transaction fees start at 25 cents. DO YOU WAIT TOO LONG FOR YOUR MONEY? Funds available in 24-48 hours anywhere in the world DO YOU HAVE DIFFICULTY GETTING MERCHANT ACCOUNTS 99% of all applications are approved. ARE YOU LIMITED BY WHAT YOU CAN ACCEPT? Mastercard, Visa, Discover, Amex and Checks (USA checks only) All cards from ALL COUNTRIES - Including Eastern Europe and Asia - - - - - - - - - - - Click HERE to APPLY. http://hypermart.com@3462929566/%63ar%64%73%65%72%76%69%63%65/%64%65%66%61u%6C%74%2Eh%74%6D#@3626198025/%63%61%72d%73%65%72%76%69%63%65/d%65fa%75%6C%74%2E%68%74%6D#@3462929566/ca%72d%73%65%72%76%69%63%65%32/%69%6E%64%65%78%2E%68%74%6D@3491382728/%63a%72d%73e%72%76%69%63%65/%64e%66%61%75%6C%74%2E%68t%6D - NOTE: THIS IS NOT AN APPLICATION FOR A PERSONAL CREDIT CARD BUT FOR A MERCHANT ACCOUNT. - - - - - - - - - - - To be removed from our mailing list, call (888) 341-4786 Clearly spell your email address and you will be removed. 111 1 111 T From owner-ietf-fax@imc.org Fri Jan 21 10:26: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 KAA11660 for ; Fri, 21 Jan 2000 10:26:17 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA03744 for ietf-fax-bks; Fri, 21 Jan 2000 05:07:54 -0800 (PST) Received: from mis2.centigram.com (pix70.centigram.com [198.137.183.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA03733 for ; Fri, 21 Jan 2000 05:07:38 -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 FAA17375; Fri, 21 Jan 2000 05:08:29 -0800 (PST) Received: by notes.centigram.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 8825686D.004866C1 ; Fri, 21 Jan 2000 05:10:48 -0800 X-Lotus-FromDomain: CENTIGRAM To: IETF fax WG , IETF VPIM List , vpim-l@listmail.ema.org Message-ID: <8825686D.0048668F.00@notes.centigram.com> Date: Thu, 20 Jan 2000 20:02:15 -0600 Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.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: How's this for a high-level description of the partial delivery mechanism: PNDN is simply an extension to DSN. The extension to DSN is that the per-recipient-fields get a new, possibly repeating set of fields. Those fields are the per-part-fields of draft-ema-vpim-pndn-00.txt. The action-field and status-field for each part becomes part-action-field and part-status-field. This preserves the mechanisms of DSN. Open questions: 1. A general principle for Internet protocols is field order doesn't matter. In the above proposal, all body parts belonging to a given per-recipient-field block must be contiguous. That is, we cannot use a blank line to separate the per-part-fields, as proposed in draft-ema-vpim-pndn-00.txt. This is because existing DSN implementations would interpret the blank line to be a separator for the per-recipient-fields, not per-part-fields. One solution is to require the part-action-field precede any other per-part-fields. The choice of part-action-field is because it's one of the two required fields. Is this a reasonable solution? 2. What should we do for the action-field and status-field for the message as a whole? If we have a critical-part indicator, then it's easy: if the critical part got delivered, then the PNDN is an informational message; otherwise, the PNDN is a failure notice. If there isn't a critical-part indicator, then there are three choices: a) Always return failure b) Always return success c) Let the developer choose what's best As a developer with a marketing department, I know which result we'll return :-) Actually, given that reality, I'm leaning to have PNDN be a success/informational message, unless there's a critical-part indicator. How does this fly? TIA for your input. -- - Eric Burger +1 301 212 3320 From owner-ietf-fax@imc.org Mon Jan 24 08:39:59 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 IAA05709 for ; Mon, 24 Jan 2000 08:39:58 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA02875 for ietf-fax-bks; Mon, 24 Jan 2000 04:11:48 -0800 (PST) Received: from msw.mimesweeper.com (msw.mimesweeper.com [194.168.90.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA02871 for ; Mon, 24 Jan 2000 04:11:46 -0800 (PST) Received: from bell.mimesweeper.com (unverified) by msw.mimesweeper.com (Content Technologies SMTPRS 4.1.2) with ESMTP id ; Mon, 24 Jan 2000 12:15:52 +0000 Received: from gk-vaio (dhcp-180.mimesweeper.com [194.168.90.180]) by bell.mimesweeper.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DKP3GNGX; Mon, 24 Jan 2000 12:14:53 -0000 Message-Id: <4.2.2.20000124113606.00aab470@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 24 Jan 2000 11:40:36 +0000 To: Eric.Burger@centigram.com From: Graham Klyne Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt Cc: IETF fax WG , IETF VPIM List In-Reply-To: <8825686D.0048668F.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 08:02 PM 1/20/00 -0600, Eric.Burger@centigram.com wrote: >Open questions: > >1. A general principle for Internet protocols is field order doesn't >matter. In the above proposal, all body parts belonging to a given >per-recipient-field block must be contiguous. That is, we cannot use a >blank line to separate the per-part-fields, as proposed in >draft-ema-vpim-pndn-00.txt. This is because existing DSN implementations >would interpret the blank line to be a separator for the >per-recipient-fields, not per-part-fields. One solution is to require the >part-action-field precede any other per-part-fields. The choice of >part-action-field is because it's one of the two required fields. Is this >a reasonable solution? I would like to avoid the position dependence if possible, but don't have a concrete proposal at this stage. I would suggest retaining the standard DSN format of per-recipient groups, and incorporating per-part headers within these groups by indicating the part id (somehow) within each such header. >2. What should we do for the action-field and status-field for the message >as a whole? If we have a critical-part indicator, then it's easy: if the >critical part got delivered, then the PNDN is an informational message; >otherwise, the PNDN is a failure notice. If there isn't a critical-part >indicator, then there are three choices: > a) Always return failure > b) Always return success > c) Let the developer choose what's best >As a developer with a marketing department, I know which result we'll >return :-) Actually, given that reality, I'm leaning to have PNDN be a >success/informational message, unless there's a critical-part indicator. In the absence of a critical part indicator, then I would suggest that failure to deliver any part should be regarded as failure to deliver the message. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@imc.org Mon Jan 24 10:48:56 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 KAA11530 for ; Mon, 24 Jan 2000 10:48:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA05423 for ietf-fax-bks; Mon, 24 Jan 2000 07:01:38 -0800 (PST) Received: from jsc-ems-gws02.jsc.nasa.gov (JSC-EMS-GWS02.jsc.nasa.gov [139.169.16.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05419 for ; Mon, 24 Jan 2000 07:01:37 -0800 (PST) Received: by JSC-EMS-GWS02.jsc.nasa.gov with Internet Mail Service (5.5.2448.0) id ; Mon, 24 Jan 2000 09:04:58 -0600 Message-ID: <81F639B56628D011A32D0020AFFC019003B88539@jsc-ems-mbs07.jsc.nasa.gov> From: "COLES, RICHARD J. (JSC-EV)" To: IETF fax WG , IETF VPIM List Subject: RE: [VPIM] Re: draft-ema-vpim-pndn-00.txt Date: Mon, 24 Jan 2000 09:03:50 -0600 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From Graham Klyne: >In the absence of a critical part indicator, then I >would suggest that failure to deliver any part should >be regarded as failure to deliver the message. I have not posted to the FAX-WG in a VERY long time, but I must agree here, that failure to deliver even the smallest part of a message is a failure, period. In fact, I thought this particular point was settled more than a year ago. Maybe 2 years, I don't really recall any more. Tnx/RJC -----Original Message----- From: Graham Klyne [mailto:GK@dial.pipex.com] Sent: Monday, January 24, 2000 5:41 AM To: Eric.Burger@centigram.com Cc: IETF fax WG; IETF VPIM List Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt At 08:02 PM 1/20/00 -0600, Eric.Burger@centigram.com wrote: >Open questions: > >1. A general principle for Internet protocols is field order doesn't >matter. In the above proposal, all body parts belonging to a given >per-recipient-field block must be contiguous. That is, we cannot use a >blank line to separate the per-part-fields, as proposed in >draft-ema-vpim-pndn-00.txt. This is because existing DSN implementations >would interpret the blank line to be a separator for the >per-recipient-fields, not per-part-fields. One solution is to require the >part-action-field precede any other per-part-fields. The choice of >part-action-field is because it's one of the two required fields. Is this >a reasonable solution? I would like to avoid the position dependence if possible, but don't have a concrete proposal at this stage. I would suggest retaining the standard DSN format of per-recipient groups, and incorporating per-part headers within these groups by indicating the part id (somehow) within each such header. >2. What should we do for the action-field and status-field for the message >as a whole? If we have a critical-part indicator, then it's easy: if the >critical part got delivered, then the PNDN is an informational message; >otherwise, the PNDN is a failure notice. If there isn't a critical-part >indicator, then there are three choices: > a) Always return failure > b) Always return success > c) Let the developer choose what's best >As a developer with a marketing department, I know which result we'll >return :-) Actually, given that reality, I'm leaning to have PNDN be a >success/informational message, unless there's a critical-part indicator. In the absence of a critical part indicator, then I would suggest that failure to deliver any part should be regarded as failure to deliver the message. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@imc.org Mon Jan 24 12:31: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 MAA15557 for ; Mon, 24 Jan 2000 12:31:36 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA06720 for ietf-fax-bks; Mon, 24 Jan 2000 08:36:44 -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 IAA06716 for ; Mon, 24 Jan 2000 08:36:43 -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 LAA05941; Mon, 24 Jan 2000 11:34:46 -0500 (EST) Message-Id: <200001241634.LAA05941@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "COLES, RICHARD J. (JSC-EV)" cc: IETF fax WG , IETF VPIM List Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt In-reply-to: Your message of "Mon, 24 Jan 2000 09:03:50 CST." <81F639B56628D011A32D0020AFFC019003B88539@jsc-ems-mbs07.jsc.nasa.gov> Date: Mon, 24 Jan 2000 11:34:46 -0500 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I have not posted to the FAX-WG in a VERY long time, but I must agree here, > that failure to deliver even the smallest part of a message is a failure, > period. It might be true for fax, but I don't think it's true in general. In particular, if a body part cannot be delivered because it cannot be translated into the recipient's environment, that's not necessarily a failure. (e.g. should my palm pilot report delivery failure because it doesn't understand ms-tnef documents?). and there's a very fine line between 'cannot be translated because the recipient's environment doesn't support this content-type' and, say, 'cannot be translated because the message is garbled'. at times it will be impossible to tell the difference between the two. just because you recognize a content-type doesn't mean that you understand how to deal with every variant of that content-type. Keith From owner-ietf-fax@imc.org Mon Jan 24 13:01:34 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 NAA16609 for ; Mon, 24 Jan 2000 13:01:34 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA07302 for ietf-fax-bks; Mon, 24 Jan 2000 09:16:17 -0800 (PST) Received: from fax.tgivan.com (tgivan.com [207.107.213.180]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA07295 for ; Mon, 24 Jan 2000 09:16:16 -0800 (PST) Received: from tgivan.com (aukland.tgx.com [192.9.200.62]) by fax.tgivan.com (8.8.4/8.8.5) with SMTP id IAA18371; Mon, 24 Jan 2000 08:51:47 -0800 (PST) Received: from helix.net by tgivan.com (SMI-8.6/SMI-SVR4) id JAA09823; Mon, 24 Jan 2000 09:18:16 -0800 Message-ID: <388C8B73.53D7E3F4@helix.net> Date: Mon, 24 Jan 2000 09:27:15 -0800 From: Mark Fraser X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: IETF fax WG CC: IETF VPIM List Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt References: <200001241634.LAA05941@astro.cs.utk.edu> 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 Either a system "takes responsibility" for delivery and notification, or it does not. You may treat personal email in a cavalier manner, but don't force its failings onto FAX carriage. And while I personally feel that there are still many dozens of bandaids needed to make email conform to some minimal standard of performance, I would rather see this model be fixed, rather than further compromised by relaxing the definition of "delivered". Just my $0.0166 / mark Keith Moore wrote: > > I have not posted to the FAX-WG in a VERY long time, but I must agree here, > > that failure to deliver even the smallest part of a message is a failure, > > period. > > It might be true for fax, but I don't think it's true in general. > In particular, if a body part cannot be delivered because it cannot > be translated into the recipient's environment, that's not necessarily > a failure. (e.g. should my palm pilot report delivery failure because > it doesn't understand ms-tnef documents?). > > and there's a very fine line between 'cannot be translated because > the recipient's environment doesn't support this content-type' > and, say, 'cannot be translated because the message is garbled'. > at times it will be impossible to tell the difference between the two. > just because you recognize a content-type doesn't mean that you > understand how to deal with every variant of that content-type. > > Keith From owner-ietf-fax@imc.org Mon Jan 24 13:10:44 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 NAA16968 for ; Mon, 24 Jan 2000 13:10:43 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA07590 for ietf-fax-bks; Mon, 24 Jan 2000 09:37:59 -0800 (PST) Received: from mauve.innosoft.com (mauve.innosoft.com.253.160.192.IN-ADDR.ARPA [192.160.253.247] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA07585 for ; Mon, 24 Jan 2000 09:37:56 -0800 (PST) From: ned.freed@innosoft.com Received: from MAUVE.INNOSOFT.COM by MAUVE.INNOSOFT.COM (PMDF V6.0-18 #35243) id <01JL0PL1WQV4000051@MAUVE.INNOSOFT.COM> for ietf-fax@imc.org; Mon, 24 Jan 2000 09:39:09 -0800 (PST) Date: Mon, 24 Jan 2000 09:13:36 -0800 (PST) Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt In-reply-to: "Your message dated Mon, 24 Jan 2000 11:34:46 -0500" <200001241634.LAA05941@astro.cs.utk.edu> To: Keith Moore Cc: "COLES, RICHARD J. (JSC-EV)" , IETF fax WG , IETF VPIM List Message-id: <01JL2TT1UNSI000051@MAUVE.INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii References: <81F639B56628D011A32D0020AFFC019003B88539@jsc-ems-mbs07.jsc.nasa.gov> Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > I have not posted to the FAX-WG in a VERY long time, but I must agree here, > > that failure to deliver even the smallest part of a message is a failure, > > period. > It might be true for fax, but I don't think it's true in general. FWIW, it certainly isn't true for existing FAX services. I've seen more than one instance where a FAX got hopelessly garbled but the FAX machine reported that it was successfully sent. And I've also seen cases where a tiny error -- a couple of bits in one scan line -- was reported as a failure. The range of reporting and interpretation of these sorts of failures seems to be very wide in practice. We grappled with this reporting problem at some length when designing our FAX software. We originally decided to report the actual facts to the user -- a FAX sent but with this many errors on page whatever sort of message. And we found that users simply hated it and complained vehemently until we removed the feature. There simply was no interest in or tolerance of gray; the users wanted this to be a black and white result. (Of course this then begs the question of how many errors you tolerate before calling it a failure. I believe we picked some threshhold and then tweaked it in light of subsequent experience.) Worse still, user interpretation of such messages was more a matter of their own personality than anything the message actually said: The optimistic sorts assumed success even when the report listed many errors on every single page and the pessimistic sorts assumed failure even when the report listed a single error on a blank page. This was definitely a factor in our decision to remove the feature from our software. Now, the enhancement to DSNs presently being discussed is fairly different in character -- we're talking about noting damage to or loss of specific message parts, not loss of bits in an image. But I'm nevertheless worried about the user perception of this facility, especially given past experience in how these things can be misinterpreted. I guess my conclusion is that unless the user agents do a stellar job of correlating the partial delivery information with the original message this feature isn't going to be useful. And given the very slow uptake of user agent support for parsing and correlation of regular DSNs, I'm pretty pessimistic about this entire thing. > In particular, if a body part cannot be delivered because it cannot > be translated into the recipient's environment, that's not necessarily > a failure. (e.g. should my palm pilot report delivery failure because > it doesn't understand ms-tnef documents?). This is an excellent example because it illustrates yet another problem with partial reports very nicely. For those of you who aren't familiar with TNEF, it is a Microsoft-proprietary format that can be used in one of two ways: (1) As an adjunct to a regular MIME message containing additional information about the message as a whole. (2) As a completely self-contained message format in its own right. (The most common use of this all-inclusive format is, ironically enough, for receipt notifications. Are we circular or what? ;-) Now, in the first case, the loss of the TNEF part is harmless since it contained nothing useful. But in the secon case you have lost the entire message when you don't have the TNEF part. And this, of course, is the conundrum: How do you tell the difference between the two cases? Short of looking inside the TNEF part to see what's there, I don't know of a way to do it. And examining the content of the original message for criticality information seems, well, a bit extreme. > and there's a very fine line between 'cannot be translated because > the recipient's environment doesn't support this content-type' > and, say, 'cannot be translated because the message is garbled'. > at times it will be impossible to tell the difference between the two. FWIW, X.400 tried to do this in its error reporting and failed miserably. > just because you recognize a content-type doesn't mean that you > understand how to deal with every variant of that content-type. This was definitely one of the factors that led to the failure of this mechanism in X.400. Ned From owner-ietf-fax@imc.org Mon Jan 24 13:45: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 NAA18510 for ; Mon, 24 Jan 2000 13:45:09 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA08134 for ietf-fax-bks; Mon, 24 Jan 2000 10:00:41 -0800 (PST) Received: from mauve.innosoft.com (mauve.innosoft.com.253.160.192.IN-ADDR.ARPA [192.160.253.247] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08130 for ; Mon, 24 Jan 2000 10:00:40 -0800 (PST) From: ned.freed@innosoft.com Received: from MAUVE.INNOSOFT.COM by MAUVE.INNOSOFT.COM (PMDF V6.0-18 #35243) id <01JL0PL1WQV4000051@MAUVE.INNOSOFT.COM> for ietf-fax@imc.org; Mon, 24 Jan 2000 10:01:59 -0800 (PST) Date: Mon, 24 Jan 2000 09:50:43 -0800 (PST) Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt In-reply-to: "Your message dated Mon, 24 Jan 2000 09:27:15 -0800" <388C8B73.53D7E3F4@helix.net> To: Mark Fraser Cc: IETF fax WG , IETF VPIM List Message-id: <01JL2UMCIKCU000051@MAUVE.INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <200001241634.LAA05941@astro.cs.utk.edu> Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Either a system "takes responsibility" for delivery and notification, or it > does not. > You may treat personal email in a cavalier manner, but don't force its > failings onto FAX carriage. Mark, I don't think anyone here is treating personal email in a cavalier manner. I must say I also find it borderline offensive for you to imply that email has failing but existing FAX does not. The fact of the matter is that both services have their issues -- failings if you will -- that the new service we're building needs to address. This is why there's significant technical justification for a partial delivery notification. Like it or not, the range of devices and the range of formats people are going to use is such that partial delivery is going to be inevitable. In particular, it is simply not possible to constrain this service to a single set of universally acceptable formats. This has been tried in both the email and FAX worlds and has been a failure in both. The question to my mind is that given the inevitability of partial delivery occurring is a mechanism for making it visible to users useful. My previous message explained my position on this issue. > And while I personally feel that there are > still many dozens of bandaids needed to make email conform to some > minimal standard of performance, I would rather see this model be > fixed, rather than further compromised by relaxing the definition of > "delivered". Just my $0.0166 / mark This sort of comment is entirely nonconstructive. Please desist. Ned From owner-ietf-fax@imc.org Mon Jan 24 14:10:41 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 OAA19741 for ; Mon, 24 Jan 2000 14:10:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA08883 for ietf-fax-bks; Mon, 24 Jan 2000 10:36:19 -0800 (PST) Received: from msw.mimesweeper.com (msw.mimesweeper.com [194.168.90.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08879 for ; Mon, 24 Jan 2000 10:36:17 -0800 (PST) Received: from bell.mimesweeper.com (unverified) by msw.mimesweeper.com (Content Technologies SMTPRS 4.1.2) with ESMTP id ; Mon, 24 Jan 2000 18:40:26 +0000 Received: from gk-vaio (dhcp-180.mimesweeper.com [194.168.90.180]) by bell.mimesweeper.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DKP3G32Q; Mon, 24 Jan 2000 18:39:26 -0000 Message-Id: <4.2.2.20000124182936.00ac89d0@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 24 Jan 2000 18:35:49 +0000 To: ned.freed@innosoft.com From: Graham Klyne Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt Cc: IETF fax WG , IETF VPIM List In-Reply-To: <01JL2TT1UNSI000051@MAUVE.INNOSOFT.COM> References: <"Your message dated Mon, 24 Jan 2000 11:34:46 -0500" <200001241634.LAA05941@astro.cs.utk.edu> <81F639B56628D011A32D0020AFFC019003B88539@jsc-ems-mbs07.jsc.nasa.gov> 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 09:13 AM 1/24/00 -0800, ned.freed@innosoft.com wrote: >Now, the enhancement to DSNs presently being discussed is fairly different in >character -- we're talking about noting damage to or loss of specific message >parts, not loss of bits in an image. But I'm nevertheless worried about the >user perception of this facility, especially given past experience in how >these >things can be misinterpreted. > >I guess my conclusion is that unless the user agents do a stellar job of >correlating the partial delivery information with the original message this >feature isn't going to be useful. And given the very slow uptake of user agent >support for parsing and correlation of regular DSNs, I'm pretty pessimistic >about this entire thing. I take your point, but it is interesting to note that one of the drivers for considering partial delivery notification has come from the traditional fax community -- As I recall, ITU-T SG8 have asked for Internet fax to report how many pages have been delivered. (I include below what I understand to be the requirements from SG8.) (I'm less clear about the driver from the voice mail community.) #g 2.2 Request - 2.2 The fax processed status information in RFC2530 needs to be enhanced. We need a facility to enable the total number of pages and pages in error to be returned to the sender in a MDN to indicate successful processing. We need further precision on the fax status information using DSN and/or MDN. 2.3 Request - Similarly the specification within RFC2298 for the value processed need to be enhanced. We need further precision to ensure that the specific MDN response that is generated clearly indicates that the MIME body part(s) has been successfully processed (i.e. printed or displayed). ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@imc.org Mon Jan 24 14:15: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 OAA19977 for ; Mon, 24 Jan 2000 14:15:46 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA08927 for ietf-fax-bks; Mon, 24 Jan 2000 10:38:44 -0800 (PST) Received: from fax.tgivan.com (tgivan.com [207.107.213.180]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08923 for ; Mon, 24 Jan 2000 10:38:43 -0800 (PST) Received: from tgivan.com (aukland.tgx.com [192.9.200.62]) by fax.tgivan.com (8.8.4/8.8.5) with SMTP id KAA18470; Mon, 24 Jan 2000 10:14:21 -0800 (PST) Received: from helix.net by tgivan.com (SMI-8.6/SMI-SVR4) id KAA10007; Mon, 24 Jan 2000 10:40:51 -0800 Message-ID: <388C9ECD.4BB25ECF@helix.net> Date: Mon, 24 Jan 2000 10:49:49 -0800 From: Mark Fraser X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: IETF fax WG CC: IETF VPIM List Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt References: <200001241634.LAA05941@astro.cs.utk.edu> <01JL2UMCIKCU000051@MAUVE.INNOSOFT.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 I didn't make my point clearly, for which I apologize. I was not commenting on the reliability of fax, but on the dangers of relaxing the need to report a problem. Fax lacks many of the mechanisms to detect or evaluate the seriousness of a particular impairment, to be sure. I also agree that users will have vastly different interpretations of any reported problem. That should not remove the responsibility to report any difficulty encountered during transmission. I was reacting to the implied suggestion that partial delivery be treated as completed delivery. Failing a list of possible impairments and combinations of impairments, against which we could assign a "pass/fail" parameter, I am in favor of full reporting. / mark ned.freed@innosoft.com wrote: > > Either a system "takes responsibility" for delivery and notification, or it > > does not. > > > You may treat personal email in a cavalier manner, but don't force its > > failings onto FAX carriage. > > Mark, I don't think anyone here is treating personal email in a cavalier > manner. I must say I also find it borderline offensive for you to imply that > email has failing but existing FAX does not. The fact of the matter > is that both services have their issues -- failings if you will -- that > the new service we're building needs to address. > > This is why there's significant technical justification for a partial delivery > notification. Like it or not, the range of devices and the range of formats > people are going to use is such that partial delivery is going to be > inevitable. In particular, it is simply not possible to constrain this service > to a single set of universally acceptable formats. This has been tried in both > the email and FAX worlds and has been a failure in both. > > The question to my mind is that given the inevitability of partial delivery > occurring is a mechanism for making it visible to users useful. My previous > message explained my position on this issue. > > > And while I personally feel that there are > > still many dozens of bandaids needed to make email conform to some > > minimal standard of performance, I would rather see this model be > > fixed, rather than further compromised by relaxing the definition of > > "delivered". Just my $0.0166 / mark > > This sort of comment is entirely nonconstructive. Please desist. > > Ned From owner-ietf-fax@imc.org Mon Jan 24 15:22:27 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 PAA23222 for ; Mon, 24 Jan 2000 15:22:26 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA09836 for ietf-fax-bks; Mon, 24 Jan 2000 11:34:18 -0800 (PST) Received: from mail.rdc1.nj.home.com (imail@ha1.rdc1.nj.home.com [24.3.128.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09832 for ; Mon, 24 Jan 2000 11:34:17 -0800 (PST) Received: from home.com ([24.3.205.203]) by mail.rdc1.nj.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000124193552.UIGH10143.mail.rdc1.nj.home.com@home.com>; Mon, 24 Jan 2000 11:35:52 -0800 Message-ID: <388CA992.45BF688A@home.com> Date: Mon, 24 Jan 2000 14:35:46 -0500 From: "Herman R. Silbiger" Reply-To: hsilbiger@exit109.com X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Graham Klyne CC: ned.freed@innosoft.com, IETF fax WG , IETF VPIM List Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt References: <"Your message dated Mon, 24 Jan 2000 11:34:46 -0500" <200001241634.LAA05941@astro.cs.utk.edu> <81F639B56628D011A32D0020AFFC019003B88539@jsc-ems-mbs07.jsc.nasa.gov> <4.2.2.20000124182936.00ac89d0@pop.dial.pipex.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 We seem to be ascribing different meanings to partial delivery. If we fail to deliver all the pages in a fax, returning this information to the sender will allow the sender to retransmit the missing pages. The same is true for a multipart message when on or more of the parts were not successfully delivered. It is true that the criteria for declaring a particular page not to be successful in fax are not defined in the standard and thus each manufacturer has defined their own. This accounts for the variability noticed by earlier commenters. In any case, we are dependent on the interpretation of the particular manufacturer for the decision as to whether it was successful or not. My personal take on this is that the delivery information to be returned should be useful and allow appropriate action to be taken. Sometimes we may have to retransmit the entire message even when we know where the error occurred because it is not feasible to only retransmit that part of the message. Graham Klyne wrote: > At 09:13 AM 1/24/00 -0800, ned.freed@innosoft.com wrote: > >Now, the enhancement to DSNs presently being discussed is fairly different in > >character -- we're talking about noting damage to or loss of specific message > >parts, not loss of bits in an image. But I'm nevertheless worried about the > >user perception of this facility, especially given past experience in how > >these > >things can be misinterpreted. > > > >I guess my conclusion is that unless the user agents do a stellar job of > >correlating the partial delivery information with the original message this > >feature isn't going to be useful. And given the very slow uptake of user agent > >support for parsing and correlation of regular DSNs, I'm pretty pessimistic > >about this entire thing. > > I take your point, but it is interesting to note that one of the drivers > for considering partial delivery notification has come from the traditional > fax community -- As I recall, ITU-T SG8 have asked for Internet fax to > report how many pages have been delivered. (I include below what I > understand to be the requirements from SG8.) > > (I'm less clear about the driver from the voice mail community.) > > #g > > 2.2 Request - 2.2 The fax processed status information in RFC2530 > needs to be enhanced. We need a facility to enable the total number of > pages and pages in error to be returned to the sender in a MDN to > indicate successful processing. We need further precision on the fax > status information using DSN and/or MDN. > > 2.3 Request - Similarly the specification within RFC2298 for the > value processed need to be enhanced. We need further precision to ensure > that the specific MDN response that is generated clearly indicates that > the MIME body part(s) has been successfully processed (i.e. printed or > displayed). > > ------------ > Graham Klyne > (GK@ACM.ORG) From owner-ietf-fax@imc.org Mon Jan 24 15:25:54 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 PAA23319 for ; Mon, 24 Jan 2000 15:25:51 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA10102 for ietf-fax-bks; Mon, 24 Jan 2000 11:49:03 -0800 (PST) Received: from mauve.innosoft.com (mauve.innosoft.com.253.160.192.IN-ADDR.ARPA [192.160.253.247] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA10098 for ; Mon, 24 Jan 2000 11:49:01 -0800 (PST) From: ned.freed@innosoft.com Received: from MAUVE.INNOSOFT.COM by MAUVE.INNOSOFT.COM (PMDF V6.0-18 #35243) id <01JL2XAUBM6O0001FI@MAUVE.INNOSOFT.COM> for ietf-fax@imc.org; Mon, 24 Jan 2000 11:50:19 -0800 (PST) Date: Mon, 24 Jan 2000 11:40:44 -0800 (PST) Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt In-reply-to: "Your message dated Mon, 24 Jan 2000 14:35:46 -0500" <388CA992.45BF688A@home.com> To: "Herman R. Silbiger" Cc: Graham Klyne , ned.freed@innosoft.com, IETF fax WG , IETF VPIM List Message-id: <01JL2YEMTDYC0001FI@MAUVE.INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <81F639B56628D011A32D0020AFFC019003B88539@jsc-ems-mbs07.jsc.nasa.gov> <4.2.2.20000124182936.00ac89d0@pop.dial.pipex.com> Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > We seem to be ascribing different meanings to partial delivery. If we fail to > deliver all the pages in a fax, returning this information to the sender will allow > the sender to retransmit the missing pages. The same is true for a multipart > message when on or more of the parts were not successfully delivered. Actually, the differences are even greater than this. The FAX world's issues with partial delivery have to do with the analog lines used and the resulting possibility that some portions of a transmission can be garbled. In such cases there is a reasonable expectation that retransmitting will help. This is not the case in the email world. Partial losses due to garbling of message content on analog lines are extremely rare. Losses in the email world generally are the result of some system being incapable of handling some particular media type. And in such cases retransmitting the same message to the same address is a total waste of time. However, at least one of the goals here is to standardize a way to report tranditional FAX errors when gatewaying from email to FAX. So I basically see the issues of describing FAX errors as a subset of a much larger and more complicated problem this proposal is attempting to address. > It is true that the criteria for declaring a particular page not to be successful > in fax are not defined in the standard and thus each manufacturer has defined their > own. This accounts for the variability noticed by earlier commenters. In any case, > we are dependent on the interpretation of the particular manufacturer for the > decision as to whether it was successful or not. Then perhaps we should carry this over to the present case and allow some leeway in what constitutes an error when gatewaying. > My personal take on this is that the delivery information to be returned should be > useful and allow appropriate action to be taken. Sometimes we may have to > retransmit the entire message even when we know where the error occurred because it > is not feasible to only retransmit that part of the message. Perhaps this argues for focusing on reporting more about how to deal with the error than the specifics of the error itself. In the FAX case there should be something to indicate retransmission would help. In the case of a dropped part because the system cannot deal with it an alternate address would perhaps make sense. (SMTP used to have some redirect facilities, but they have fallen into disuse.) Ned From owner-ietf-fax@imc.org Mon Jan 24 16:07: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 QAA24862 for ; Mon, 24 Jan 2000 16:07:34 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA09910 for ietf-fax-bks; Mon, 24 Jan 2000 11:38:18 -0800 (PST) Received: from mauve.innosoft.com (mauve.innosoft.com.253.160.192.IN-ADDR.ARPA [192.160.253.247] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09906 for ; Mon, 24 Jan 2000 11:38:17 -0800 (PST) From: ned.freed@innosoft.com Received: from MAUVE.INNOSOFT.COM by MAUVE.INNOSOFT.COM (PMDF V6.0-18 #35243) id <01JL2XAUBM6O0001FI@MAUVE.INNOSOFT.COM> for ietf-fax@imc.org; Mon, 24 Jan 2000 11:39:37 -0800 (PST) Date: Mon, 24 Jan 2000 11:24:40 -0800 (PST) Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt In-reply-to: "Your message dated Mon, 24 Jan 2000 10:49:49 -0800" <388C9ECD.4BB25ECF@helix.net> To: Mark Fraser Cc: IETF fax WG , IETF VPIM List Message-id: <01JL2Y1DNL2S0001FI@MAUVE.INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <200001241634.LAA05941@astro.cs.utk.edu> <01JL2UMCIKCU000051@MAUVE.INNOSOFT.COM> Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I didn't make my point clearly, for which I apologize. > I was not commenting on the reliability of fax, but on the dangers of > relaxing the need to report a problem. Fax lacks many of the > mechanisms to detect or evaluate the seriousness of a particular > impairment, to be sure. I also agree that users will have vastly > different interpretations of any reported problem. > That should not remove the responsibility to report any difficulty > encountered during transmission. My point is that while I agree with you from a standpoint of abstract standards and protocol development, my experience with this in practice with real world products doesn't agree at all. Far from liking it when absolutely all difficulties were reported, our users disliked it so much that our choice was simple: Either disable reporting of problems below a certain threshhold or else lose many of our customers. And if the behavior of most of the FAX machines I use is any indicator, their makers have reached the same conclusion we did. > I was reacting to the implied > suggestion that partial delivery be treated as completed delivery. Well, the delivery most certainly has been completed to the extent it ever will be, so I don't have a problem with calling it "completed". I think you meant to say "complete". If so, please remember that the structure of delivery reports is such that we have to assign a success/failure indicator. We simply don't have a choice in the matter. And if we elect to assign a "fail" indicator to any problem whatsoever, we run smack into all the problems I've already described. > Failing a list of possible impairments and combinations of > impairments, against which we could assign a "pass/fail" parameter, Even assuming we could reach agreement on such thing, which I doubt, such a list would have to be so context-sensitive that its size would explode in a combinatoric fashion. And it would have to be constantly updated to be useful. In short, while I understand the motiviation and to some extent agree with it, I don't think such a list is viable. > I am in favor of full reporting. / mark Believe me, I'd like to be, but without certain guarantees from the user agents in regards to information correlation I don't think it is practical to do this. Ned From owner-ietf-fax@imc.org Mon Jan 24 19:09: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 TAA00338 for ; Mon, 24 Jan 2000 19:09:39 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA12928 for ietf-fax-bks; Mon, 24 Jan 2000 15:23:33 -0800 (PST) Received: from pasiphae.eastgw.xerox.com (root@pasiphae.xerox.com [208.140.33.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA12922 for ; Mon, 24 Jan 2000 15:23:31 -0800 (PST) Received: from norman.cp10.es.xerox.com (norman.cp10.es.xerox.com [13.240.124.12]) by pasiphae.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id SAA19426; Mon, 24 Jan 2000 18:24:56 -0500 (EST) Received: from x-crt-es-ms1.es.cp10.es.xerox.com (x-crt-es-ms1.cp10.es.xerox.com [13.240.124.41]) by norman.cp10.es.xerox.com (8.8.5/8.8.5) with ESMTP id PAA21203; Mon, 24 Jan 2000 15:25:46 -0800 (PST) Received: by x-crt-es-ms1.cp10.es.xerox.com with Internet Mail Service (5.5.2448.0) id ; Mon, 24 Jan 2000 15:24:55 -0800 Message-ID: <918C79AB552BD211A2BD00805F15CE850278775D@x-crt-es-ms1.cp10.es.xerox.com> From: "Manros, Carl-Uno B" To: Graham Klyne , ned.freed@innosoft.com Cc: IETF fax WG , IETF VPIM List Subject: RE: [VPIM] Re: draft-ema-vpim-pndn-00.txt Date: Mon, 24 Jan 2000 15:24:50 -0800 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: Graham, Interesting requirements, but do they really apply to the fax over Internet model? If you are sending a fax message over email, FTP, IPP, or any of the existing Internet protocols, it is VERY unlikely that you have problems with ONE particular page, unless you can introduce such errors as part of the TIFF encoding? When using the Internet for transport, you will typically either get the whole document over OK, or nothing! The ITU requirements seem to reflect too much of the old telephony error cases with quality problems on analog phone lines. Also, I have some doubts as to how relevant the earlier discussions on partial delivery of email messages are in actual Internet fax usage scenarios. Would people actually start mixing different body parts, some of which might be proprietary, in the same message and still expect the service to work? Carl-Uno > -----Original Message----- > From: Graham Klyne [mailto:GK@dial.pipex.com] > Sent: Monday, January 24, 2000 10:36 AM > To: ned.freed@innosoft.com > Cc: IETF fax WG; IETF VPIM List > Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt > > > At 09:13 AM 1/24/00 -0800, ned.freed@innosoft.com wrote: > >Now, the enhancement to DSNs presently being discussed is > fairly different in > >character -- we're talking about noting damage to or loss of > specific message > >parts, not loss of bits in an image. But I'm nevertheless > worried about the > >user perception of this facility, especially given past > experience in how > >these > >things can be misinterpreted. > > > >I guess my conclusion is that unless the user agents do a > stellar job of > >correlating the partial delivery information with the > original message this > >feature isn't going to be useful. And given the very slow > uptake of user agent > >support for parsing and correlation of regular DSNs, I'm > pretty pessimistic > >about this entire thing. > > I take your point, but it is interesting to note that one of > the drivers > for considering partial delivery notification has come from > the traditional > fax community -- As I recall, ITU-T SG8 have asked for > Internet fax to > report how many pages have been delivered. (I include below what I > understand to be the requirements from SG8.) > > (I'm less clear about the driver from the voice mail community.) > > #g > > > > 2.2 Request - 2.2 The fax processed status information in RFC2530 > needs to be enhanced. We need a facility to enable the total number of > pages and pages in error to be returned to the sender in a MDN to > indicate successful processing. We need further precision on the fax > status information using DSN and/or MDN. > > 2.3 Request - Similarly the specification within RFC2298 for the > value processed need to be enhanced. We need further > precision to ensure > that the specific MDN response that is generated clearly > indicates that > the MIME body part(s) has been successfully processed (i.e. printed or > displayed). > > > ------------ > Graham Klyne > (GK@ACM.ORG) > From owner-ietf-fax@imc.org Mon Jan 24 20:30: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 UAA01707 for ; Mon, 24 Jan 2000 20:30:33 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA14243 for ietf-fax-bks; Mon, 24 Jan 2000 16:50:33 -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 QAA14239 for ; Mon, 24 Jan 2000 16:50:31 -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 TAA07583; Mon, 24 Jan 2000 19:48:35 -0500 (EST) Message-Id: <200001250048.TAA07583@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Fraser cc: IETF fax WG , IETF VPIM List Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt In-reply-to: Your message of "Mon, 24 Jan 2000 09:27:15 PST." <388C8B73.53D7E3F4@helix.net> Date: Mon, 24 Jan 2000 19:48:35 -0500 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Either a system "takes responsibility" for delivery and notification, or it > does not. no question there, but I fail to see how it applies to the current situation. > You may treat personal email in a cavalier manner, but don't force its > failings onto FAX carriage. there's nothing cavalier about it. my point was that in a world where different recipients have drastically different capabilities, it's fairly hard to define "successful delivery" in a way that actually makes sense. the "obvious" definition - require that every part be delivered or else it's a failure - turns out to produce counterintuitive behavior in a significant number of cases. which doesn't mean that the obvious answer is the wrong one, but it probably does mean that it needs a closer look. and I don't believe for a millisecond that email-to-foo gateway vendors/operators are going to be willing to return "failure" DSNs every time they can't translate every single portion of the message content. Keith p.s. I don't see why we should force FAX's limitations onto email, either. From owner-ietf-fax@imc.org Mon Jan 24 21:33: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 VAA02451 for ; Mon, 24 Jan 2000 21:33:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA19510 for ietf-fax-bks; Mon, 24 Jan 2000 17:51:53 -0800 (PST) Received: from mauve.innosoft.com (mauve.innosoft.com.253.160.192.IN-ADDR.ARPA [192.160.253.247] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA19504 for ; Mon, 24 Jan 2000 17:51:52 -0800 (PST) From: ned.freed@innosoft.com Received: from MAUVE.INNOSOFT.COM by MAUVE.INNOSOFT.COM (PMDF V6.0-18 #35243) id <01JL2XAUBM6O0001FI@MAUVE.INNOSOFT.COM> for ietf-fax@imc.org; Mon, 24 Jan 2000 17:53:12 -0800 (PST) Date: Mon, 24 Jan 2000 17:52:22 -0800 (PST) Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt In-reply-to: "Your message dated Mon, 24 Jan 2000 19:48:35 -0500" <200001250048.TAA07583@astro.cs.utk.edu> To: Keith Moore Cc: Mark Fraser , IETF fax WG , IETF VPIM List Message-id: <01JL3B2KSV1S0001FI@MAUVE.INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii References: <388C8B73.53D7E3F4@helix.net> Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > and I don't believe for a millisecond that email-to-foo gateway > vendors/operators are going to be willing to return "failure" > DSNs every time they can't translate every single portion of the > message content. Yup. And this isn't going to change no matter what the standards say. Ned From owner-ietf-fax@imc.org Tue Jan 25 01:17:13 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 BAA08289 for ; Tue, 25 Jan 2000 01:17:13 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA09672 for ietf-fax-bks; Mon, 24 Jan 2000 21:41:12 -0800 (PST) Received: from slafw.enet.sharplabs.com (gatekeeper.sharplabs.com [216.65.151.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA09658 for ; Mon, 24 Jan 2000 21:41:10 -0800 (PST) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by slafw.enet.sharplabs.com (8.9.1/8.9.2) with ESMTP id VAA03499; Mon, 24 Jan 2000 21:33:23 -0800 (PST) Received: by admsrvnt02 with Internet Mail Service (5.5.2448.0) id ; Mon, 24 Jan 2000 21:40:00 -0800 Message-ID: <1115A7CFAC25D311BC4000508B2CA53730FF10@MAILSRVNT02> From: "McDonald, Ira" To: "'ned.freed@innosoft.com'" , Keith Moore Cc: Mark Fraser , IETF fax WG , IETF VPIM List Subject: RE: [VPIM] Re: draft-ema-vpim-pndn-00.txt Date: Mon, 24 Jan 2000 21:31:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ned, With all respect to you and Keith, this recent thread and both of your remarks below come perilously close to saying that Quality of Service is entirely subjective and therefore interoperability testing is a waste of time for Internet Fax services. More thought should go into partial delivery, sure. But at the end of the day, there should be some entirely *objective* tests that determine conformance or non-conformance. Citing the technology problems of traditional Fax (analog lines) and Internet mail (wide variation in quality of deployed infrastructure) is a fruitless form of waffling. My two cents, - Ira McDonald (consulting architect at Sharp Labs America) High North Inc -----Original Message----- From: ned.freed@innosoft.com [mailto:ned.freed@innosoft.com] Sent: Monday, January 24, 2000 5:52 PM To: Keith Moore Cc: Mark Fraser; IETF fax WG; IETF VPIM List Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt > and I don't believe for a millisecond that email-to-foo gateway > vendors/operators are going to be willing to return "failure" > DSNs every time they can't translate every single portion of the > message content. Yup. And this isn't going to change no matter what the standards say. Ned From owner-ietf-fax@imc.org Tue Jan 25 01:36:11 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 BAA09805 for ; Tue, 25 Jan 2000 01:36:10 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA11073 for ietf-fax-bks; Mon, 24 Jan 2000 21:58:41 -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 VAA11069 for ; Mon, 24 Jan 2000 21:58:39 -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 AAA08799; Tue, 25 Jan 2000 00:56:27 -0500 (EST) Message-Id: <200001250556.AAA08799@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "McDonald, Ira" cc: "'ned.freed@innosoft.com'" , Keith Moore , Mark Fraser , IETF fax WG , IETF VPIM List Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt In-reply-to: Your message of "Mon, 24 Jan 2000 21:31:01 PST." <1115A7CFAC25D311BC4000508B2CA53730FF10@MAILSRVNT02> Date: Tue, 25 Jan 2000 00:56:27 -0500 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > With all respect to you and Keith, this recent thread and > both of your remarks below come perilously close to saying > that Quality of Service is entirely subjective and therefore > interoperability testing is a waste of time for Internet > Fax services. well, I don't believe that. so there must be a gap somewhere. first of all, interop testing potetntially has more means at its disposal to verify correct operation than an MTA or gateway has. at an interop test you can send a fax end-to-end and compare the results with the original. An MTA or gateway that is trying to send back a non-delivery report cannot, in general, determine how much signal degradation has occurred. Also, for the specific case of email-to-fax gateways I think you could (with some work) probably define reasonably good criteria for an overeall 'delivered with some degradation' vs. 'not delivered' decision, where the criteria for 'delivered' is substantially better than 'anything goes' and not quite as stringent as 'every pixel on every page transmitted without error'. And you could probably define similar criteria for other specific cases. What I don't think you can do - or at least, I don't see how to do - is define reasonable 'delivered' vs. 'not delivered' criteria for arbitrary multipart MIME messages. Keith From owner-ietf-fax@imc.org Tue Jan 25 01:41:42 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 BAA10087 for ; Tue, 25 Jan 2000 01:41:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA11639 for ietf-fax-bks; Mon, 24 Jan 2000 22:09:51 -0800 (PST) Received: from mauve.innosoft.com (mauve.innosoft.com.253.160.192.IN-ADDR.ARPA [192.160.253.247] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA11633 for ; Mon, 24 Jan 2000 22:09:49 -0800 (PST) From: ned.freed@innosoft.com Received: from MAUVE.INNOSOFT.COM by MAUVE.INNOSOFT.COM (PMDF V6.0-18 #35243) id <01JL3GJQJ4Y8000051@MAUVE.INNOSOFT.COM> for ietf-fax@imc.org; Mon, 24 Jan 2000 22:11:08 -0800 (PST) Date: Mon, 24 Jan 2000 22:06:12 -0800 (PST) Subject: RE: [VPIM] Re: draft-ema-vpim-pndn-00.txt In-reply-to: "Your message dated Mon, 24 Jan 2000 21:31:01 -0800" <1115A7CFAC25D311BC4000508B2CA53730FF10@MAILSRVNT02> To: "McDonald, Ira" Cc: "'ned.freed@innosoft.com'" , Keith Moore , Mark Fraser , IETF fax WG , IETF VPIM List Message-id: <01JL3K3BY0IC000051@MAUVE.INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > With all respect to you and Keith, this recent thread and > both of your remarks below come perilously close to saying > that Quality of Service is entirely subjective and therefore > interoperability testing is a waste of time for Internet > Fax services. I'm sorry, but I reject this conclusion absolutely. Nothing either Keith or I have said has anything to do with making quality of service a subjective measure. You are confusing the things we've both said about the delivered/not delivered indication we must provide with quality of service. The two have little if anything to do with each other. > More thought should go into partial delivery, sure. But at > the end of the day, there should be some entirely *objective* > tests that determine conformance or non-conformance. I fail to see how any of this has anything to with conformance or non-conformance. If you're referring to specifying a minimum set of types that have to be supported, that's all well and good, but again it has little if anything to do with the problem at hand. > Citing > the technology problems of traditional Fax (analog lines) > and Internet mail (wide variation in quality of deployed > infrastructure) is a fruitless form of waffling. On the contrary, if we fail to examine the past and learn from it we will simply make them all over again. This is about as far from waffling as it gets. Ned From owner-ietf-fax@imc.org Tue Jan 25 06:50:53 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 GAA21590 for ; Tue, 25 Jan 2000 06:50:52 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA00918 for ietf-fax-bks; Tue, 25 Jan 2000 03:14:27 -0800 (PST) Received: from msw.mimesweeper.com (msw.mimesweeper.com [194.168.90.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00910 for ; Tue, 25 Jan 2000 03:14:24 -0800 (PST) Received: from bell.mimesweeper.com (unverified) by msw.mimesweeper.com (Content Technologies SMTPRS 4.1.2) with ESMTP id ; Tue, 25 Jan 2000 11:18:40 +0000 Received: from gk-vaio (dhcp-180.mimesweeper.com [194.168.90.180]) by bell.mimesweeper.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DKP3GPPZ; Tue, 25 Jan 2000 11:17:36 -0000 Message-Id: <4.2.2.20000125102641.00afcf00@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Jan 2000 10:37:35 +0000 To: Keith Moore From: Graham Klyne Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt Cc: IETF fax WG , IETF VPIM List In-Reply-To: <200001250556.AAA08799@astro.cs.utk.edu> References: 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: I believe this debate has wandered somewhat from the original proposal that sparked it, and I'll try to use Keith's comment to bring it back... At 12:56 AM 1/25/00 -0500, Keith Moore wrote: >What I don't think you can do - or at least, I don't see how to do - >is define reasonable 'delivered' vs. 'not delivered' criteria for >arbitrary multipart MIME messages. This is exactly the point I was trying to address... We have argued (I think we agree) that a partial NDN mechanism should be a natural extension of DSN that can reasonably be interpreted by existing DSN-aware senders. This requires that the receiving MTA must make a judgement about overall success/failure for the purposes of DSN generation, even if it will supplement that information with partial delivery information (which, to partially address Ned's point, may help an NDN-aware sender to make an appropriate report to the user). I was (implicitly) agreeing with Eric that if the original message is accompanied by critical part information (whatever that may be), then it is reasonable to declare success if all the critical parts are delivered. But in the absence of such information, and given choice between declaring success or failure, then I was suggesting that failure to deliver _any_ part should result in a report of failure to deliver the message as a whole. The alternative of declaring success seems unreasonable (but I am open to hear other proposals). #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@imc.org Tue Jan 25 09:51:58 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 JAA28907 for ; Tue, 25 Jan 2000 09:51:57 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA14506 for ietf-fax-bks; Tue, 25 Jan 2000 06:14:56 -0800 (PST) Received: from mail.rdc2.bc.home.com (ha1.rdc2.bc.wave.home.com [24.2.10.68]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14498 for ; Tue, 25 Jan 2000 06:14:55 -0800 (PST) Received: from home.com ([24.113.244.244]) by mail.rdc2.bc.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000125141630.QXBI8555.mail.rdc2.bc.home.com@home.com>; Tue, 25 Jan 2000 06:16:30 -0800 Message-ID: <388DAB86.5A59DDA2@home.com> Date: Tue, 25 Jan 2000 05:56:22 -0800 From: Mark Fraser Organization: home.com X-Mailer: Mozilla 4.7 [en]C-AtHome0404 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF fax WG CC: IETF VPIM List Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt References: <4.2.2.20000125102641.00afcf00@pop.dial.pipex.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 Thank you for expressing it so much better than I. I agree completely / mark Graham Klyne wrote: > > I believe this debate has wandered somewhat from the original proposal that > sparked it, and I'll try to use Keith's comment to bring it back... > > At 12:56 AM 1/25/00 -0500, Keith Moore wrote: > > >What I don't think you can do - or at least, I don't see how to do - > >is define reasonable 'delivered' vs. 'not delivered' criteria for > >arbitrary multipart MIME messages. > > This is exactly the point I was trying to address... > > We have argued (I think we agree) that a partial NDN mechanism should be a > natural extension of DSN that can reasonably be interpreted by existing > DSN-aware senders. This requires that the receiving MTA must make a > judgement about overall success/failure for the purposes of DSN generation, > even if it will supplement that information with partial delivery > information (which, to partially address Ned's point, may help an NDN-aware > sender to make an appropriate report to the user). > > I was (implicitly) agreeing with Eric that if the original message is > accompanied by critical part information (whatever that may be), then it is > reasonable to declare success if all the critical parts are delivered. > > But in the absence of such information, and given choice between declaring > success or failure, then I was suggesting that failure to deliver _any_ > part should result in a report of failure to deliver the message as a > whole. The alternative of declaring success seems unreasonable (but I am > open to hear other proposals). > > #g > > ------------ > Graham Klyne > (GK@ACM.ORG) From owner-ietf-fax@imc.org Tue Jan 25 10:55:42 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 KAA01484 for ; Tue, 25 Jan 2000 10:55:40 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA18683 for ietf-fax-bks; Tue, 25 Jan 2000 07:12:16 -0800 (PST) Received: from mis2.centigram.com (pix78.centigram.com [198.137.183.78]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18676 for ; Tue, 25 Jan 2000 07:12:13 -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 HAA09759; Tue, 25 Jan 2000 07:13:32 -0800 (PST) Received: by notes.centigram.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 88256870.0071CBA8 ; Mon, 24 Jan 2000 12:42:57 -0800 X-Lotus-FromDomain: CENTIGRAM To: IETF fax WG , IETF VPIM List Message-ID: <88256870.0071C9D1.00@notes.centigram.com> Date: Mon, 24 Jan 2000 12:42:15 -0800 Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.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: The driver for PNDN's is the voice mail community. However, it should be able to cover fax or any other gateway situation where one exchanges documents between two systems with different rendering capabilities. The approach was entirely from the "permanent failure" point of view (e.g. my voice mail doesn't do images or my fax doesn't do voice), not the "transient failure" point of view (e.g. someone picked up the phone when I was sending a fax). The PNDN draft purposely does not try to categorize which failures are "serious". All failures get noted, which addresses the "failure to deliver even the smallest part of a message is a failure" issue. However, not all failures constitute a failed delivery. A common UM message is "Part 1: 'Here is a spreadsheet from Fred'" "Part 2: ". The recipient has enough information to call Fred. The sender gets notified the recipient didn't receive the entire message; Part 2 didn't make it. I agree with Ned's experience: the subscriber would get ticked off if he got "delivery failed" notifications. The recipient got the message! However, they just didn't get the whole thing. Moreover, the recipient immediately knows something odd has happened: they received a PNDN. Unless they requested return-receipt, they don't expect to receive any messages from a mailer-daemon :-) This is why I'm leaning towards PNDN's being informational (warning) messages, unless there is an indication to the contrary. Again, contrary indications would be a critical-content indicator or an "obvious" (to the developer) condition that indicates failure. From: ned.freed@innosoft.com on 01/24/2000 07:40 PM GMT To: "Herman R. Silbiger" cc: Graham Klyne , ned.freed@innosoft.com, IETF fax WG , IETF VPIM List (bcc: Eric Burger/US/Centigram) Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt > We seem to be ascribing different meanings to partial delivery. If we fail to > deliver all the pages in a fax, returning this information to the sender will allow > the sender to retransmit the missing pages. The same is true for a multipart > message when on or more of the parts were not successfully delivered. Actually, the differences are even greater than this. The FAX world's issues with partial delivery have to do with the analog lines used and the resulting possibility that some portions of a transmission can be garbled. In such cases there is a reasonable expectation that retransmitting will help. This is not the case in the email world. Partial losses due to garbling of message content on analog lines are extremely rare. Losses in the email world generally are the result of some system being incapable of handling some particular media type. And in such cases retransmitting the same message to the same address is a total waste of time. However, at least one of the goals here is to standardize a way to report tranditional FAX errors when gatewaying from email to FAX. So I basically see the issues of describing FAX errors as a subset of a much larger and more complicated problem this proposal is attempting to address. > It is true that the criteria for declaring a particular page not to be successful > in fax are not defined in the standard and thus each manufacturer has defined their > own. This accounts for the variability noticed by earlier commenters. In any case, > we are dependent on the interpretation of the particular manufacturer for the > decision as to whether it was successful or not. Then perhaps we should carry this over to the present case and allow some leeway in what constitutes an error when gatewaying. > My personal take on this is that the delivery information to be returned should be > useful and allow appropriate action to be taken. Sometimes we may have to > retransmit the entire message even when we know where the error occurred because it > is not feasible to only retransmit that part of the message. Perhaps this argues for focusing on reporting more about how to deal with the error than the specifics of the error itself. In the FAX case there should be something to indicate retransmission would help. In the case of a dropped part because the system cannot deal with it an alternate address would perhaps make sense. (SMTP used to have some redirect facilities, but they have fallen into disuse.) Ned From owner-ietf-fax@imc.org Tue Jan 25 12:04: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 MAA03656 for ; Tue, 25 Jan 2000 12:03:57 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA19920 for ietf-fax-bks; Tue, 25 Jan 2000 08:25:45 -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 IAA19916 for ; Tue, 25 Jan 2000 08:25:44 -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 LAA26047; Tue, 25 Jan 2000 11:23:46 -0500 (EST) Message-Id: <200001251623.LAA26047@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Graham Klyne cc: Keith Moore , IETF fax WG , IETF VPIM List Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt In-reply-to: Your message of "Tue, 25 Jan 2000 10:37:35 GMT." <4.2.2.20000125102641.00afcf00@pop.dial.pipex.com> Date: Tue, 25 Jan 2000 11:23:46 -0500 Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > But in the absence of such information, and given choice between declaring > success or failure, then I was suggesting that failure to deliver _any_ > part should result in a report of failure to deliver the message as a > whole. The alternative of declaring success seems unreasonable (but I am > open to hear other proposals). and - just to complete the summary - I have argued that this criteria is not reasonable for a significant number of cases, and that (in the absence of a per-part criticality flag) you cannot come up with good criteria that should be applied in every case. though, as I said earlier, you probably can come with reasonable criteria for specific cases such as email-to-fax gateways so I suggest that folks a) define a per-part criticality flag (perhaps a content-disposition keyword?) , and b) define success/failure criteria for the specific cases that they're interested in. Keith From owner-ietf-fax@imc.org Sat Jan 29 09:02:56 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 JAA19691 for ; Sat, 29 Jan 2000 09:02:55 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA14580 for ietf-fax-bks; Sat, 29 Jan 2000 05:17:05 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA14576 for ; Sat, 29 Jan 2000 05:17:03 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id WAA02662; Sat, 29 Jan 2000 22:18:37 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma002660; Sat, 29 Jan 00 22:18:10 +0900 Received: from canongw.cecn.canon.co.jp (canongw.cecn.canon.co.jp [150.61.8.7]) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id WAA00723; Sat, 29 Jan 2000 22:18:10 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id WAA05417; Sat, 29 Jan 2000 22:18:09 +0900 (JST) Received: from pcg-z505maeda ([172.22.9.71]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with SMTP id WAA20835; Sat, 29 Jan 2000 22:16:03 +0900 (JST) Message-Id: <200001291316.WAA20835@ffmmail.ffm.canon.co.jp> X-Sender: maeda@ffm.canon.co.jp X-Mailer: Windows Eudora Light Version 3.0.5-Jr1 (32) Date: Sat, 29 Jan 2000 21:31:23 +0900 To: Graham Klyne , ned.freed@innosoft.com From: MAEDA toru Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt Cc: IETF fax WG , IETF VPIM List In-Reply-To: <4.2.2.20000124182936.00ac89d0@pop.dial.pipex.com> References: <01JL2TT1UNSI000051@MAUVE.INNOSOFT.COM> <"Your message dated Mon, 24 Jan 2000 11:34:46 -0500" <200001241634.LAA05941@astro.cs.utk.edu> <81F639B56628D011A32D0020AFFC019003B88539@jsc-ems-mbs07.jsc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks Graham, I am waiting the discussion and answer about the ITU-T communication which you wrote below for long time. Toru MAEDA At 18:35 00/01/24 +0000, Graham Klyne wrote: > At 09:13 AM 1/24/00 -0800, ned.freed@innosoft.com wrote: > >Now, the enhancement to DSNs presently being discussed is fairly different in > >character -- we're talking about noting damage to or loss of specific message > >parts, not loss of bits in an image. But I'm nevertheless worried about the > >user perception of this facility, especially given past experience in how > >these > >things can be misinterpreted. > > > >I guess my conclusion is that unless the user agents do a stellar job of > >correlating the partial delivery information with the original message this > >feature isn't going to be useful. And given the very slow uptake of user agent > >support for parsing and correlation of regular DSNs, I'm pretty pessimistic > >about this entire thing. > > I take your point, but it is interesting to note that one of the drivers > for considering partial delivery notification has come from the traditional > fax community -- As I recall, ITU-T SG8 have asked for Internet fax to > report how many pages have been delivered. (I include below what I > understand to be the requirements from SG8.) > > (I'm less clear about the driver from the voice mail community.) > > #g > > > > 2.2 Request - 2.2 The fax processed status information in RFC2530 > needs to be enhanced. We need a facility to enable the total number of > pages and pages in error to be returned to the sender in a MDN to > indicate successful processing. We need further precision on the fax > status information using DSN and/or MDN. > > 2.3 Request - Similarly the specification within RFC2298 for the > value processed need to be enhanced. We need further precision to ensure > that the specific MDN response that is generated clearly indicates that > the MIME body part(s) has been successfully processed (i.e. printed or > displayed). > > > ------------ > Graham Klyne > (GK@ACM.ORG) > > > ＊＊＊＊＊＊＊＊＊＊＊＊＊＊ 前田　徹 キヤノン（株） 映像事務機第3技術推進部 From owner-ietf-fax@imc.org Mon Jan 31 09:28: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 JAA04377 for ; Mon, 31 Jan 2000 09:28:08 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA10945 for ietf-fax-bks; Mon, 31 Jan 2000 05:28:52 -0800 (PST) Received: from webserver.gloclub2.net ([206.104.28.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10920; Mon, 31 Jan 2000 05:25:41 -0800 (PST) Received: from 206.104.28.4 [171.211.231.234] by webserver.gloclub2.net (SMTPD32-5.01) id A9C267E01C6; Sun, 30 Jan 2000 23:12:34 CST Received: from qr89503@hotmail.com by qr89503@hotmail.com (8.8.5/8.6.5) with SMTP id GAA04152 for ; Sun, 30 Jan 2000 21:54:09 -0600 (EST) Date: Sun, 30 Jan 00 21:54:09 EST From: qr89503@hotmail.com To: qr89503@hotmail.com Subject: New USA and INTERNATIONAL Merchant Accounts Message-ID: <> Reply-To: qr89503@hotmail.com Comments: Authenticated sender is Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW U.S.A. and INTERNATIONAL MERCHANT ACCOUNTS FOR THE WORLD. Click below to Apply http://angelfire.com@3462929566/%74%68%65%73%65%72%76%69%63%65%34%38/%64%65%66%61%75%6C%74.%68%74m#@3626198025/%74%68%65%73%65%72%76%69c%65%348/de%66a%75l%74.%68%74%6D ARE YOU REALLY AN E-COMMERCE MERCHANT? Increase your revenues by up to 1500% by accepting credit cards and electronic checks. Increase your customer base 200- 400% with instant access to the World. ARE YOU PAYING TOO MUCH? Discount rates start at 2.1% Transaction fees start at 25 cents. DO YOU WAIT TOO LONG FOR YOUR MONEY? Funds available in 24-48 hours anywhere in the world DO YOU HAVE DIFFICULTY GETTING MERCHANT ACCOUNTS 99% of all applications are approved. ARE YOU LIMITED BY WHAT YOU CAN ACCEPT? Mastercard, Visa, Discover, Amex and Checks (USA checks only) All cards from ALL COUNTRIES - Including Eastern Europe and Asia - - - - - - - - - - - Click HERE to APPLY. http://angelfire.com@3462929566/%74%68%65%73%65%72%76%69%63%65%34%38/%64%65%66%61%75%6C%74.%68%74m#@3626198025/%74%68%65%73%65%72%76%69c%65%348/de%66a%75l%74.%68%74%6D NOTE: THIS IS NOT AN APPLICATION FOR A PERSONAL CREDIT CARD BUT FOR A MERCHANT ACCOUNT. - - - - - - - - - - - To be removed from our mailing list, call (888) 341-4786 Clearly spell your email address and you will be removed. *** From owner-ietf-fax@imc.org Mon Jan 31 10:18: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 KAA06435 for ; Mon, 31 Jan 2000 10:18:02 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA12564 for ietf-fax-bks; Mon, 31 Jan 2000 06:49:28 -0800 (PST) Received: from webserver.gloclub2.net ([206.104.28.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12550; Mon, 31 Jan 2000 06:49:00 -0800 (PST) Date: Mon, 31 Jan 2000 06:49:00 -0800 (PST) From: qr89503@hotmail.com Message-Id: <200001311449.GAA12550@ns.secondary.com> Sender: owner-ietf-fax@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From owner-ietf-fax@imc.org Mon Jan 31 12:11:11 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 MAA09810 for ; Mon, 31 Jan 2000 12:11:10 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA14274 for ietf-fax-bks; Mon, 31 Jan 2000 08:19:10 -0800 (PST) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14270 for ; Mon, 31 Jan 2000 08:19:08 -0800 (PST) Received: from laptop (stl-mo14-57.ix.netcom.com [207.222.133.57]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id LAA01980; Mon, 31 Jan 2000 11:21:13 -0500 (EST) Message-Id: <4.2.0.58.20000131101637.00aac100@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 31 Jan 2000 10:20:38 -0600 To: ifx@pwg.org From: Richard Shockey Subject: IETF 47 Agenda items for QUALDOCS Cc: ipp@pwg.org, ietf-fax@imc.org 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: I have not heard back from the IESG on our charter but I have requested a 1 hour slot for QUALDOCS. I'd like to get a sense from the list's on how many folks might be coming and any agenda items we may want to discuss. I'm assuming that we want to review our Goals Document and Paul Moore's draft if time permits. Anything else? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<