From owner-ietf-fax@mail.imc.org Wed Aug 2 20:39: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 UAA22924 for ; Wed, 2 Aug 2000 20:39:56 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA26563 for ietf-fax-bks; Wed, 2 Aug 2000 16:48:34 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA26559 for ; Wed, 2 Aug 2000 16:48:31 -0700 (PDT) Date: Thu, 3 Aug 2000 01:51:40 +0100 To: ietf-fax@imc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: IETF-48 Fax WG minutes (short draft notes) Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallo, thanks to Graham which is always very quick, here are our summary notes for this morning meeting. Moer detailed minutes will then follow. Please submit since now changes, and corrections/additions to this short list. regards, ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Project Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://security.fi.infn.it/cgi-bin/spgpk.pl?KeyId=0C5C2A09 IETF-48 Fax WG minutes Claudio Allocchio and Hiroshi Tamura briefly introduce the meeting, and welcome participants in Pittsburgh. 1. TIFF-FX to Draft Standard Lloyd McIntyre presents changes to TIFF-FX specification (-07) -- these are purely editorial. With these changes, document will go forward in IESG without new last call. THe Document is currently in AD review status. 2. Simple mode service document to Draft Standard status Toyoda-san presents revisions [see slides] -- all minor changes Awaiting three normative references moving to Draft: File format, address format, format extensions for DSN reports. 3. Minimal addressing format document Claudio presents revisions -- minor clarification and a correction to ABNF. 4. Fax addressing format document Claudio presents. Clarification of sub-address format -- digits only, no '#', no spaces, no multiple sub-addresses. Include IANA registration procedures (copied from RFC 2846 -- full address document). 5. RFC 2304 interworking report from Japan Toyoda-san presents. Attendees: TOYOCOM and MGCS. [See side for test configuration] See slides for test cases. All items from "RFC 2304 interworking configuration matrix" (per FaxConnect 2) were satisfied -- see FaxConnect 2 web site. (Paul Hoffman, do you have the exact URL, please?) As such a "formal" interoperability report will be submitted to IESG and the last call to Draft Standard will be issued. 6. Internet fax gateway considerations ??? (TOYOCOM) presents. (This presentaton was supported by some slides with excellent diagrams covering the issues discussed.) Internet fax gateway has two functions: onramp and offramp [See slides] + Addressing issues [see slides] Question about about provision for separate identification of country code, to allow receiving system to isolate local dialling part. The standard defines only fully qualified numbers with leading '+', so system should know to expect a country code. Other numbers do not have a defined meaning, and is not appropriate to try and specify behaviour in these cases. Should a receiver be expected to know its own local dialing codes? Beyond scope of this specification, but implementations will need to take account of these issues. Suggested text: "Gateway MUST process the mailbox string and convert it to a local dial string according to the local dialing rules". + File format conversion issues [see slides] + Drop duplications [see slides] Same message to multiple mailboxes at the same domain. There is some confusion about exactly what this means. From the draft: An offramp gateway MUST drop the duplicate mail by confirming whether Message-ID is the same as old one. This is to avoid the duplication of the transmission to same facsimile device over GSTN. It is suggested that the MUST be softened to MAY or SHOULD. Message IDs cannot be guaranteed to be unique (e-mail specs notwithstanding). Also, note that mailing lists can change text without changing message-ID. Question: what is scope of duplicate detection (period of time). + Automatic retransmission [see slide] Is there provision in the spec to link any retransmissions to the original? Note that retransmissions must be constrained to local legal operating requirements? Add a note that retransmission issues may be particularly sensitive, and must be handled with care, because the sending user will not generally be present to deal with any transmission failures? + Error behaviour [see slide] Need to distinguish between T.30/fax "soft" errors (for which retransmission may be appropriate -- e.g. line busy) and "hard errors" (for which retransmission is not appropriate -- e.g. paper out). + Onramp gateway Note: current version is based strictly on simple mode (c.f. section 4.1) We need to decide (on the list) whether we wish to be restricted to this scope, or whether to address extended/full mode issues from the start. + Addressing fax-to-fax From the draft: An onramp gateway MUST have the function that onramp gateway analyze destination address from address data sent by facsimile device over GSTN Direct and indirect addressing are discussed. Direct uses given number directly as mailbox name, and uses prefix to select destination domain. Indirect may use number mapping table to select destination mailbox and domain. + Next version -01 Not distributed at time of meeting, but has been prepared. See slides for summary of changes. 7. Implementer's guide Vivian Cancio presents. (See slides) Addresses simple and extended modes. Question: is there a reasonable mechanism for a sender to determine whether or not an MDN/DSN has been sent *after* the TIFF image has been processed? This information may be useful to automatic status logging systems. 8. FFPIM GK presents. Timely delivery draft will be moved forward now DELIVERBY is an RFC. There are a number of technical issues in the negotiation draft that really should have some group discussion on the list. They are highlighted in the draft -- please review and comment. For now: Note that there may be security concerns (message tracing) if negotiation is allowed with recipients not named by the sender. The distinction between 'definitive' and 'informative' introduces some unintended complexities, and the "sender decides" model for quality decisions seems to be adequate. Don't do this for now. 9. TIFF-FX extensions Lloyd presents. See slides. Slide 27 contains overview of relation of changes to current TIFF-FX profiles. The enhancements require new tags to be approved by Adobe, for which a formal WG request may be required. 10. VPIM/IVM activities Glen Parsons presents. See slides. Concerns expressed about 'content-hint' -- careful discussion needed. 11. ITU interactions Tamura-san presents. See slides. 12. Terminal mode Maeda-san presents. See slides. 13. Charter review No objections. Call to all members to please get draft reviews in quickly. From owner-ietf-fax@mail.imc.org Thu Aug 10 19:45: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 TAA16452 for ; Thu, 10 Aug 2000 19:45:56 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA19460 for ietf-fax-bks; Thu, 10 Aug 2000 16:13:08 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA19454 for ; Thu, 10 Aug 2000 16:13:06 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA05930; Thu, 10 Aug 2000 16:12:27 -0700 (PDT) Message-Id: <200008102312.QAA05930@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2880 on Internet Fax T.30 Feature Mapping Cc: rfc-ed@ISI.EDU, ietf-fax@imc.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 10 Aug 2000 16:12:27 -0700 From: RFC Editor Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2880 Title: Internet Fax T.30 Feature Mapping Author(s): L. McIntyre, G. Klyne Status: Informational Date: July 2000 Mailbox: Lloyd.McIntyre@pahv.xerox.com, GK@ACM.ORG Pages: 37 Characters: 75973 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-fax-feature-T30-mapping-03.txt URL: ftp://ftp.isi.edu/in-notes/rfc2880.txt This document describes how to map Group 3 fax capability identification bits, described in ITU T.30, into the Internet fax feature schema described in "Content feature schema for Internet fax". This is a companion to the fax feature schema document, which itself defines a profile of the media feature registration mechanisms, for use in performing capability identification between extended Internet fax systems. This document is a product of the Internet Fax Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000810161005.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2880 --OtherAccess Content-Type: Message/External-body; name="rfc2880.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000810161005.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Thu Aug 10 19: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 TAA16535 for ; Thu, 10 Aug 2000 19:47:58 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA19195 for ietf-fax-bks; Thu, 10 Aug 2000 16:10:14 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA19191 for ; Thu, 10 Aug 2000 16:10:12 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA05413; Thu, 10 Aug 2000 16:09:32 -0700 (PDT) Message-Id: <200008102309.QAA05413@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2879 on Content Feature Schema for Internet Fax (V2) Cc: rfc-ed@ISI.EDU, ietf-fax@imc.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 10 Aug 2000 16:09:32 -0700 From: RFC Editor Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2879 Title: Content Feature Schema for Internet Fax (V2) Author(s): G. Klyne, L. McIntyre Status: Standards Track Date: July 2000 Mailbox: GK@ACM.ORG, Lloyd.McIntyre@pahv.xerox.com Pages: 58 Characters: 104032 Obsoletes: 2531 I-D Tag: draft-ietf-fax-feature-schema-v2-01.txt URL: ftp://ftp.isi.edu/in-notes/rfc2879.txt This document defines a content media feature schema for Internet fax. It is a profile of the media feature registration mechanisms [1,2,3] for use in performing capability identification between extended Internet fax systems [5]. It replaces and updates the feature schema defined in RFC 2531. This document is a product of the Internet Fax Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000810160654.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2879 --OtherAccess Content-Type: Message/External-body; name="rfc2879.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000810160654.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Thu Aug 10 20:34: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 UAA17380 for ; Thu, 10 Aug 2000 20:34:27 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA22087 for ietf-fax-bks; Thu, 10 Aug 2000 16:57:23 -0700 (PDT) Received: from picard.noroff.no ([212.20.204.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA22081 for ; Thu, 10 Aug 2000 16:57:21 -0700 (PDT) Received: by picard.noroff.no (Postfix, from userid 815) id B42DA22002; Fri, 11 Aug 2000 02:40:58 +0200 (CEST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id 1AF7CB3802 for ; Fri, 11 Aug 2000 02:40:56 +0200 (CEST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id TAA09033 for ietf-123-outbound.09@ietf.org; Thu, 10 Aug 2000 19:15:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id TAA09004 for ; Thu, 10 Aug 2000 19:09:33 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15692 for ; Thu, 10 Aug 2000 19:09:33 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA05413; Thu, 10 Aug 2000 16:09:32 -0700 (PDT) Message-Id: <200008102309.QAA05413@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2879 on Content Feature Schema for Internet Fax (V2) Cc: rfc-ed@ISI.EDU, ietf-fax@imc.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 10 Aug 2000 16:09:32 -0700 From: RFC Editor X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2879 Title: Content Feature Schema for Internet Fax (V2) Author(s): G. Klyne, L. McIntyre Status: Standards Track Date: July 2000 Mailbox: GK@ACM.ORG, Lloyd.McIntyre@pahv.xerox.com Pages: 58 Characters: 104032 Obsoletes: 2531 I-D Tag: draft-ietf-fax-feature-schema-v2-01.txt URL: ftp://ftp.isi.edu/in-notes/rfc2879.txt This document defines a content media feature schema for Internet fax. It is a profile of the media feature registration mechanisms [1,2,3] for use in performing capability identification between extended Internet fax systems [5]. It replaces and updates the feature schema defined in RFC 2531. This document is a product of the Internet Fax Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000810160654.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2879 --OtherAccess Content-Type: Message/External-body; name="rfc2879.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000810160654.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Thu Aug 10 20:39:06 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 UAA17432 for ; Thu, 10 Aug 2000 20:39:05 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA22119 for ietf-fax-bks; Thu, 10 Aug 2000 16:58:01 -0700 (PDT) Received: from picard.noroff.no ([212.20.204.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA22115 for ; Thu, 10 Aug 2000 16:57:59 -0700 (PDT) Received: by picard.noroff.no (Postfix, from userid 815) id 517E622002; Fri, 11 Aug 2000 02:41:37 +0200 (CEST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id 1AD68B3802 for ; Fri, 11 Aug 2000 02:41:35 +0200 (CEST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id TAA09080 for ietf-123-outbound.09@ietf.org; Thu, 10 Aug 2000 19:25:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id TAA09012 for ; Thu, 10 Aug 2000 19:12:27 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15761 for ; Thu, 10 Aug 2000 19:12:27 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA05930; Thu, 10 Aug 2000 16:12:27 -0700 (PDT) Message-Id: <200008102312.QAA05930@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2880 on Internet Fax T.30 Feature Mapping Cc: rfc-ed@ISI.EDU, ietf-fax@imc.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 10 Aug 2000 16:12:27 -0700 From: RFC Editor X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2880 Title: Internet Fax T.30 Feature Mapping Author(s): L. McIntyre, G. Klyne Status: Informational Date: July 2000 Mailbox: Lloyd.McIntyre@pahv.xerox.com, GK@ACM.ORG Pages: 37 Characters: 75973 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-fax-feature-T30-mapping-03.txt URL: ftp://ftp.isi.edu/in-notes/rfc2880.txt This document describes how to map Group 3 fax capability identification bits, described in ITU T.30, into the Internet fax feature schema described in "Content feature schema for Internet fax". This is a companion to the fax feature schema document, which itself defines a profile of the media feature registration mechanisms, for use in performing capability identification between extended Internet fax systems. This document is a product of the Internet Fax Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000810161005.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2880 --OtherAccess Content-Type: Message/External-body; name="rfc2880.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000810161005.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Fri Aug 11 02:42:43 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 CAA06249 for ; Fri, 11 Aug 2000 02:42:42 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA19062 for ietf-fax-bks; Thu, 10 Aug 2000 23:08:24 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA19057 for ; Thu, 10 Aug 2000 23:08:22 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id PAA21416 for ; Fri, 11 Aug 2000 15:07:03 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id PAA24338 for ; Fri, 11 Aug 2000 15:07:03 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id PAA02866 for ; Fri, 11 Aug 2000 15:06:58 +0900 To: ietf-fax@imc.org Subject: FAX WG slides at Pittsburgh meeting X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000811150818R.tamura@toda.ricoh.co.jp> Date: Fri, 11 Aug 2000 15:08:18 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, Pittsburgh meeting slides are already in the following address, as usual. http://www.imc.org/ietf-fax/ Paul, thank you for your support. BTW, I go into vacation mode soon. I will be back on Aug 21 or 22. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Mon Aug 14 07:49: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 HAA04179 for ; Mon, 14 Aug 2000 07:49:48 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA08764 for ietf-fax-bks; Mon, 14 Aug 2000 04:02:15 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08760 for ; Mon, 14 Aug 2000 04:02:14 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03309; Mon, 14 Aug 2000 07:01:53 -0400 (EDT) Message-Id: <200008141101.HAA03309@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-tiff-fx-07.txt Date: Mon, 14 Aug 2000 07:01:53 -0400 Sender: owner-ietf-fax@mail.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 : File Format for Internet Fax Author(s) : R. Buckley, D. Venable, S. Zilles, L. McIntyre, G. Parsons, J. Rafferty Filename : draft-ietf-fax-tiff-fx-07.txt Pages : 86 Date : 11-Aug-00 This document is a revised version of Proposed Standard RFC 2301. The revisions, summarized in the list attached as Annex C to this document, are based on the discussions and suggestions for improvements that have been made since the Proposed Standard was issued in March 1998, and on the results of independent implementations and interoperability testing. This RFC 2301 revision describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF-FX. It formally defines minimal, extended and lossless JBIG profiles (Profiles S, F, J) for black-and-white fax, and base JPEG, lossless JBIG and Mixed Raster Content profiles (Profiles C, L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations. Files formatted according to this specification use the image/tiff MIME Content Type. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-tiff-fx-07.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-tiff-fx-07.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-tiff-fx-07.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: <20000811092558.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-tiff-fx-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-tiff-fx-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000811092558.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Mon Aug 14 10:29: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 KAA09686 for ; Mon, 14 Aug 2000 10:29:57 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA11496 for ietf-fax-bks; Mon, 14 Aug 2000 06:51:49 -0700 (PDT) Received: from picard.noroff.no ([212.20.204.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11490 for ; Mon, 14 Aug 2000 06:51:47 -0700 (PDT) Received: by picard.noroff.no (Postfix, from userid 815) id 6DCC72201F; Mon, 14 Aug 2000 16:36:05 +0200 (CEST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id 1C5F5B3803 for ; Mon, 14 Aug 2000 16:36:03 +0200 (CEST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA19607 for ietf-123-outbound.09@ietf.org; Mon, 14 Aug 2000 08:55:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18734 for ; Mon, 14 Aug 2000 07:01:53 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03309; Mon, 14 Aug 2000 07:01:53 -0400 (EDT) Message-Id: <200008141101.HAA03309@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-tiff-fx-07.txt Date: Mon, 14 Aug 2000 07:01:53 -0400 X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2 Sender: owner-ietf-fax@mail.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 : File Format for Internet Fax Author(s) : R. Buckley, D. Venable, S. Zilles, L. McIntyre, G. Parsons, J. Rafferty Filename : draft-ietf-fax-tiff-fx-07.txt Pages : 86 Date : 11-Aug-00 This document is a revised version of Proposed Standard RFC 2301. The revisions, summarized in the list attached as Annex C to this document, are based on the discussions and suggestions for improvements that have been made since the Proposed Standard was issued in March 1998, and on the results of independent implementations and interoperability testing. This RFC 2301 revision describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF-FX. It formally defines minimal, extended and lossless JBIG profiles (Profiles S, F, J) for black-and-white fax, and base JPEG, lossless JBIG and Mixed Raster Content profiles (Profiles C, L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations. Files formatted according to this specification use the image/tiff MIME Content Type. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-tiff-fx-07.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-tiff-fx-07.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-tiff-fx-07.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: <20000811092558.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-tiff-fx-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-tiff-fx-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000811092558.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Tue Aug 15 08:35:24 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 IAA12912 for ; Tue, 15 Aug 2000 08:35:24 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA18219 for ietf-fax-bks; Tue, 15 Aug 2000 05:00:31 -0700 (PDT) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA18207 for ; Tue, 15 Aug 2000 05:00:28 -0700 (PDT) Received: from HALVESTR-8KCDT.maxware.no (ams-vpdn-client-450.cisco.com [144.254.47.198]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id OAA23002 for ; Tue, 15 Aug 2000 14:00:10 +0200 Message-Id: <4.3.2.7.2.20000815135117.01df22a0@nordic.cisco.com> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Aug 2000 13:59:44 +0200 To: ietf-fax@imc.org From: Harald Alvestrand Subject: Query: Internationalization in addressing components? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, I just had reason to discover this quandary: RFC 2846 (GSTN address elements) defines quite a number of elements that have names as their content, including, but not limited to: - ATTN - ORG - OFNA - STR - ADDR Yet their definition is done without specifying any mechanism for encoding non-ASCII characters. This makes them useless for specifying a large percentage of the person names in the world, for one thing. Could I have a few words from the group on the logic behind this choice? Harald A -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-fax@mail.imc.org Wed Aug 16 05:52:12 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 FAA20792 for ; Wed, 16 Aug 2000 05:52:11 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA02806 for ietf-fax-bks; Wed, 16 Aug 2000 02:14:41 -0700 (PDT) Received: from nemesis.worldnet.net (nemesis.worldnet.net [195.3.3.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA02798 for ; Wed, 16 Aug 2000 02:14:39 -0700 (PDT) Received: from m1.worldnet.net (m1.worldnet.net [195.3.3.5]) by nemesis.worldnet.net (8.9.3/8.9.3) with ESMTP id LAA97323 for ; Wed, 16 Aug 2000 11:19:37 +0200 (CEST) Received: from lucien (i07-105.paris.worldnet.fr [195.3.7.105] (may be forged)) by m1.worldnet.net (8.9.3/8.9.3) with SMTP id LAA28367 for ; Wed, 16 Aug 2000 11:14:09 +0200 (CEST) Message-ID: <01de01c00762$12148ce0$1300000a@lucien> From: "Lucien Lumbroso" To: References: <4.3.2.7.2.20000815135117.01df22a0@nordic.cisco.com> Subject: T44 Date: Wed, 16 Aug 2000 08:43:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Do you know some fax machine with T44 features for interoperability testing. Thanks Lucien LUMBROSO lucien.lumbroso@affixcce.com web: www.affixcce.com CCE: 33 1 39 35 48 80 From owner-ietf-fax@mail.imc.org Thu Aug 17 07:32: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 HAA23890 for ; Thu, 17 Aug 2000 07:32:38 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA03200 for ietf-fax-bks; Thu, 17 Aug 2000 03:57:43 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA03196 for ; Thu, 17 Aug 2000 03:57:41 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23241; Thu, 17 Aug 2000 06:57:35 -0400 (EDT) Message-Id: <200008171057.GAA23241@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-gateway-protocol-01.txt Date: Thu, 17 Aug 2000 06:57:35 -0400 Sender: owner-ietf-fax@mail.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 Gateway Protocol Author(s) : K. Mimura, K. Yokoyama, T. Satoh, C. Kanaide Filename : draft-ietf-fax-gateway-protocol-01.txt Pages : 12 Date : 16-Aug-00 An Internet FAX Gateway provides functions which translate facsimile between the general switched telephone network (GSTN) the Internet. This document provides information on recommended behaviors for Internet FAX Gateways Protocol. In this context, an Offramp means facsimile data transmission to the GSTN from the Internet, and onramp means facsimile data transmission to Internet from the GSTN. This document covers the delivery-process of the data among equipment which may include Internet Fax terminals, PCs on the Internet and FAX terminal on GSTN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-protocol-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-gateway-protocol-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-gateway-protocol-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: <20000816095139.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-gateway-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-gateway-protocol-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000816095139.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Thu Aug 17 08:44: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 IAA25554 for ; Thu, 17 Aug 2000 08:44:58 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA08602 for ietf-fax-bks; Thu, 17 Aug 2000 05:08:29 -0700 (PDT) Received: from picard.noroff.no ([212.20.204.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08591 for ; Thu, 17 Aug 2000 05:08:26 -0700 (PDT) Received: by picard.noroff.no (Postfix, from userid 815) id ED7C722003; Thu, 17 Aug 2000 14:53:17 +0200 (CEST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id A519FB3802 for ; Thu, 17 Aug 2000 14:53:15 +0200 (CEST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA28438 for ietf-123-outbound.09@ietf.org; Thu, 17 Aug 2000 07:15:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA28333 for ; Thu, 17 Aug 2000 06:57:35 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23241; Thu, 17 Aug 2000 06:57:35 -0400 (EDT) Message-Id: <200008171057.GAA23241@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-gateway-protocol-01.txt Date: Thu, 17 Aug 2000 06:57:35 -0400 X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2 Sender: owner-ietf-fax@mail.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 Gateway Protocol Author(s) : K. Mimura, K. Yokoyama, T. Satoh, C. Kanaide Filename : draft-ietf-fax-gateway-protocol-01.txt Pages : 12 Date : 16-Aug-00 An Internet FAX Gateway provides functions which translate facsimile between the general switched telephone network (GSTN) the Internet. This document provides information on recommended behaviors for Internet FAX Gateways Protocol. In this context, an Offramp means facsimile data transmission to the GSTN from the Internet, and onramp means facsimile data transmission to Internet from the GSTN. This document covers the delivery-process of the data among equipment which may include Internet Fax terminals, PCs on the Internet and FAX terminal on GSTN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-protocol-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-gateway-protocol-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-gateway-protocol-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: <20000816095139.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-gateway-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-gateway-protocol-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000816095139.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Thu Aug 17 13:37:15 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 NAA01207 for ; Thu, 17 Aug 2000 13:37:15 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA26608 for ietf-fax-bks; Thu, 17 Aug 2000 10:08:12 -0700 (PDT) Received: from mail.yourdomain.com (m319-mp1-cvx1a.man.ntl.com [62.252.197.63]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA26173; Thu, 17 Aug 2000 09:58:55 -0700 (PDT) From: announce@leisurewebcams.com Message-Id: <200008171658.JAA26173@ns.secondary.com> Date: Thu, 17 Aug 2000 14:23:35 Subject: LeisureWebcams.com - See the World Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LeisureWebcams.com is a recently launched website specialising in providing free LIVE access to over 1,500 webcams and 2,000 Tourist Offices world wide. Check it out:- http://www.leisurewebcams.com/ This offers you the chance to check out live and frequently updated images of your chosen location through the webcams and get detailed local knowledge through the Tourist Offices. Along with booking holidays direct through our travel partner, there is the opportunity to sell your unwanted clothes and equipment through our free Swap Shop. There is a lot to see, so if you have enjoyed your trip through our site, do tell your friends and let us know through 'Your Views'. If you have any suggestions for the site, or queries, please feel free to contact me at cy@LeisureWebcams.com. I look forward to hearing from you. Kind regards, Charlie Yates MARKETING DIRECTOR LeisureWebcams.com From owner-ietf-fax@mail.imc.org Fri Aug 18 22:31:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14623 for ; Fri, 18 Aug 2000 22:31:52 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA11112 for ietf-fax-bks; Fri, 18 Aug 2000 18:53:43 -0700 (PDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA11106 for ; Fri, 18 Aug 2000 18:53:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA25601; Fri, 18 Aug 2000 18:52:44 -0700 (PDT) Date: Fri, 18 Aug 2000 18:52:43 -0700 (PDT) From: Dan Wing To: Harald Alvestrand cc: ietf-fax@imc.org Subject: Re: Query: Internationalization in addressing components? In-Reply-To: <4.3.2.7.2.20000815135117.01df22a0@nordic.cisco.com> Message-ID: <0008181849030.19999-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It's a good idea. But how would a receiver decide if the following three forms are supposed to be equal? /ATTN==?ISO-8859-1?Q?Patrik.F=E4ltstr=F6m?= /ATTN==?US-ASCII?Q?Patrik.Faltstrom?= /ATTN=Patrik.Faltstrom Perhaps we could just require that text after ATTN, ORG, OFNA, STR, and ADDR shouldn't be matched exactly? -d On Tue, 15 Aug 2000 13:59 +0200, Harald Alvestrand wrote: > Hello, > I just had reason to discover this quandary: > > RFC 2846 (GSTN address elements) defines quite a number of elements that > have names as their content, including, but not limited to: > > - ATTN > - ORG > - OFNA > - STR > - ADDR > > Yet their definition is done without specifying any mechanism for encoding > non-ASCII characters. > This makes them useless for specifying a large percentage of the person > names in the world, for one thing. > > Could I have a few words from the group on the logic behind this choice? > > Harald A > > > -- > Harald Tveit Alvestrand, alvestrand@cisco.com > +47 41 44 29 94 > Personal email: Harald@Alvestrand.no > From owner-ietf-fax@mail.imc.org Sun Aug 20 11:29:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08517 for ; Sun, 20 Aug 2000 11:29:07 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA17632 for ietf-fax-bks; Sun, 20 Aug 2000 07:49:39 -0700 (PDT) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17628 for ; Sun, 20 Aug 2000 07:49:36 -0700 (PDT) Received: from HALVESTR-8KCDT.maxware.no (sj-isp-nat-pool-34.cisco.com [204.69.198.34]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id QAA12223; Sun, 20 Aug 2000 16:49:32 +0200 Message-Id: <4.3.2.7.2.20000819093136.02a23ef8@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 19 Aug 2000 09:33:19 -0700 To: Dan Wing From: Harald Alvestrand Subject: Re: Query: Internationalization in addressing components? Cc: ietf-fax@imc.org In-Reply-To: <0008181849030.19999-100000@omega.cisco.com> References: <4.3.2.7.2.20000815135117.01df22a0@nordic.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 18:52 18/08/2000 -0700, Dan Wing wrote: >It's a good idea. > >But how would a receiver decide if the following three forms are supposed >to be equal? > > /ATTN==?ISO-8859-1?Q?Patrik.F=E4ltstr=F6m?= > /ATTN==?US-ASCII?Q?Patrik.Faltstrom?= > /ATTN=Patrik.Faltstrom > >Perhaps we could just require that text after ATTN, ORG, OFNA, STR, and >ADDR shouldn't be matched exactly? The most common reason for ATTN is to print on fax cover pages; there is no standard way to transfer the ATTN information across a T.4/T.20 fax call. So the important thing is to make sure the offramp (fax sender) understands the character set; exact matching isn't that important. IMHO. Harald -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-fax@mail.imc.org Mon Aug 21 03:08:43 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 DAA27922 for ; Mon, 21 Aug 2000 03:08:42 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA27458 for ietf-fax-bks; Sun, 20 Aug 2000 23:10:50 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA27452 for ; Sun, 20 Aug 2000 23:10:44 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id PAA04053 for ; Mon, 21 Aug 2000 15:10:57 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id PAA26370 for ; Mon, 21 Aug 2000 15:10:53 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id PAA12787 for ; Mon, 21 Aug 2000 15:10:45 +0900 To: ietf-fax@imc.org Subject: draft minutes of FAX WG at Pittsburgh X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Aug_21_15:11:38_2000_955)--" Content-Transfer-Encoding: 7bit Message-Id: <20000821151221R.tamura@toda.ricoh.co.jp> Date: Mon, 21 Aug 2000 15:12:21 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 378 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----Next_Part(Mon_Aug_21_15:11:38_2000_955)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, I'm back from holiday. Attached is the draft minutes at Pittsburgh meeting. We are pressed and asked to submit soon. Thanks to Graham, I was able to finish it soon. I appreciate his usual effort of taking minutes. Please check it. If there are issues to modify and any other missing points, please let me know or circulate by Wednesday(Aug 23, ET). ^^^^^^^^^^^^^^^^^^^^^^^^ I'd like to submit on Aug 24(JST). Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp ----Next_Part(Mon_Aug_21_15:11:38_2000_955)-- Content-Type: Text/Plain; charset=us-ascii Content-Disposition: attachment; filename="pit_fax-wg_minutes.txt" Content-Transfer-Encoding: 7bit ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Minutes of Internet fax WG (fax) at IETF-48 Pittsburgh ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 9:00 - 11:30, August 2, 2000 Chaired by Claudio Allocchio and Hiroshi Tamura Reported by Graham Klyne and Hiroshi Tamura All slides at the meeting are found at the following URL: http://www.imc.org/ietf-fax/ ---------------------------------------------------------------------- 1 Agenda bashing ---------------------------------------------------------------------- Claudio Allocchio introduced the agenda and it was accepted. ---------------------------------------------------------------------- 2 Status of pending Draft Standards ---------------------------------------------------------------------- It is about update of file format for internet fax (TIFF-FX: RFC 2301). Lloyd McIntyre presented changes to TIFF-FX specification (draft-ietf-fax-tiff-fx-07.txt), which were not formally distributed before the meeting. It was confirmed the changes are purely editorial. Sooner or later, it is announced for the distribution. The version 06 is now under Draft Standard consideration. With these changes, document will go forward in IESG without new last call. ---------------------------------------------------------------------- 3 Targeted for Draft Standard ---------------------------------------------------------------------- ---------------------------------------------------------------------- 3.1 Service ---------------------------------------------------------------------- It is about update of RFC 2305. Kiyoshi Toyoda introduced draft-ietf-fax-service-v2-02.txt, which mentions simple mode fax in internet mail. He presented revisions, which are mainly about non-normative issues. All are the minor editorial changes. It was confirmed that the following three normative references need to move to Draft Standard. - File format (RFC 2301) - Fax address format (RFC 2304) - Format extensions for DSN reports (RFC 1894) ---------------------------------------------------------------------- 3.2 Addressing ---------------------------------------------------------------------- It is about update of RFC 2303 and 2304. Claudio Allocchio introduced draft-ietf-fax-minaddr-v2-01.txt, which mentions minimal GSTN address format in internet mail (RFC 2303). He presented the revisions, which are minor clarification and a correction to ABNF. He also introduced draft-ietf-fax-faxaddr-v2-01.txt, which mentions minimal fax address format in internet mail (RFC 2304). He presented clarification of sub-address format (ITU-T T.33, T.30). Digits are only allowed in it, and '#' and spaces are not allowed. No multiple sub-addresses are allowed. He also introduced RFC 2846 (full addressing), which includes many pre-defined address elements and IANA registration procedures. Kiyoshi Toyoda introduced interworking report about RFC 2304, in order to elevate RFC 2304 to Draft Standard. There are two attendees:TOYOCOM and MGCS. There was a test configuration in which a IFAX device sends document to an offramp gateway through internet and the gateway sends to G3 fax or onramp fax for sub-address. All syntax defined in RFC 2304 were tried for test. The tests satisfied the items of "RFC 2304 interworking configuration Matrix" which has delivered to Fax Connect 2 (http://www.imc.org/imc-faxconnect/). It was confirmed that "formal" report is necessary for request of Draft Standard consideration. ---------------------------------------------------------------------- 4 Internet-Drafts ---------------------------------------------------------------------- ---------------------------------------------------------------------- 4.1 Gateway issue ---------------------------------------------------------------------- Katsuhiko Mimura presented draft-ietf-fax-gateway-protocol-00.txt. It mentions internet fax gateway protocol which has two functions: onramp and offramp. a) Addressing How offramp gateway extract fax number from mail address was introduced. A question was raised about provision for separate identification of country code, to allow receiving system to isolate local dialing part. The standard defines only fully qualified numbers with leading '+', so system should know to expect a country code. Other numbers do not have a defined meaning, and is not appropriate to try and specify behaviour in these cases. Should a receiver be expected to know its own local dialing codes ? Beyond scope of this specification, but implementations needs to take account of these issues. Suggested text is as follows: "Gateway MUST process the mailbox string and convert it to a local dial string according to the local dialing rules". b) File format conversion There is difference between the format of internet fax (TIFF-FX) and the one of GSTN fax. Some conversion is necessary. c) Drop duplications There are the same messages to multiple mail boxes at the same domain. There is some confusion about exactly what this means. There is the following descriptions in the draft: An offramp gateway MUST drop the duplicate mail by confirming whether Message-ID is the same as old one. This is to avoid the duplication of the transmission to same facsimile device over GSTN. It is suggested that the MUST be softened to MAY or SHOULD. Message IDs cannot be guaranteed to be unique (notwithstanding e-mail specification). Also, it is noted that mailing lists can change text without changing message-ID. A question was raised on what is scope of duplicate detection (period of time). d) Automatic retransmission An offramp gateway may automatically retry to send fax data in the case of delivery failure. Questions were raised on whether or not specification to link any retransmissions to the original ones is provided and whether or not retransmissions must be constrained to local legal operating requirements. There was a comment that retransmission specification is not described in ITU-T T.30. It was commented to add a note that retransmission issues may be particularly sensitive, and must be handled with care, because the sending user will not generally be present to deal with any transmission failures. e) Error behaviour Retransmission depends on the contents of errors. It is necessary to to distinguish between T.30/fax "soft" errors (for which retransmission may be appropriate -- e.g. line busy) and "hard" errors (for which retransmission is not appropriate -- e.g. paper out). He suggests this issue should be addressed in another draft. f) Return notice When mail to fax is multicast or broadcast and a delivery error happens, there is an issue about when and how return notice should be done. He suggests this issue should also be addressed in another draft. g) Onramp gateway Onramp gateway functions fax to mail. It is noted that current version is based strictly on simple mode. But, WG may need to decide whether we wish to be restricted to this scope, or whether to address extended /full mode issues from the start. h) Addressing with FAX terminal There is the following description in the draft: An onramp gateway MUST have the function that onramp gateway analyze destination address from address data sent by facsimile device over GSTN. Direct and indirect addressing are discussed. Direct uses given number directly as mailbox name, and uses prefix to select destination domain. Indirect may use number mapping table to select destination mailbox and domain. i) Authorization by DTMF It is necessary that authorization should be done at onramp gateway. GSTN users send UserID and Password to onramp gateway in some ways such as sending DTMF after dialing. j) Next version -01 He promises to announce the next version soon. ---------------------------------------------------------------------- 4.2 Implementers Guide ---------------------------------------------------------------------- Vivian Cancio presented draft-ietf-fax-implementers-guide-02.txt. It is a guide for simple and extended modes. She explained changes to current drafts. There are mainly corrections to the examples (MDN and MTA/ESMTP) and the addition of the case of receiving multiple TIFF attachments, in which it is recommended extended mode recipient returns an error when it is unable to decode any of the attached files. A question was raised on a reasonable mechanism for a sender to determine whether or not an MDN/DSN has been sent *after* the TIFF image has been processed. This information may be useful to automatic status logging systems. ---------------------------------------------------------------------- 4.3 FFPIM ---------------------------------------------------------------------- Graham Klyne presented it. it consists of the following three drafts. a) draft-ietf-fax-ffpim-00.txt b) draft-ietf-fax-timely-delivery-00.txt c) draft-ietf-fax-content-negotiation-02.txt Timely delivery draft will be moved forward, because now DELIVERBY has become RFC 2852. Concerning content negotiation, he explained the overview again. There are a number of technical issues in the negotiation draft that really should have some group discussion on the list, such as use of 'Original -recipient", content-id, cache-control, "content-alternative" header, MDN extensions. They are highlighted in the draft. Further suggestions and comments are invited. For now, it is noted that there may be security concerns (message tracing) if negotiation is allowed with recipients not named by the sender. The distinction between 'definitive' and 'informative' introduces some unintended complexities, and the "sender decides" model for quality decisions seems to be adequate. But it is noted that it should not be done for now. ---------------------------------------------------------------------- 4.4 TIFF-FX extension issue ---------------------------------------------------------------------- Lloyd McIntyre presented it. It is not formally distributed. But it is draft-mcintyre-fax-tiff-fx-extension-00.txt in http://www.imc.org/ draft-mcintyre-fax-tiff-fx-extension. From the contents of the Adelaide meeting in March, MRC:multi-strip background and foreground layers and Annotation are deleted, because they are immature. They are candidate for future draft. Therefore, the extension includes new field values and/or relaxed constraints (higher resolutions and MRC with more than 3 MRC layers) and new fields and/or profiles(more than one profile within document and JBIG2). He presented these new field values like 600x600dpi, relaxed constrains like more than 3 MRC layers, JBIG2 etc. He also explained overview of relation of changes to current TIFF-FX profiles. It was confirmed that the enhancements require new tags to be approved by Adobe, for which a formal WG request may be required. ---------------------------------------------------------------------- 5 Issue from VPIM WG ---------------------------------------------------------------------- Glenn Parsons, who is a co-chair of VPIM WG, introduced the internet fax related issues discussed in VPIM WG. ---------------------------------------------------------------------- 5.1 Partial Non-Delivery Notifications (draft-ietf-vpim-pndn-00.txt) ---------------------------------------------------------------------- It describes the interaction between systems sending multipart Internet main to systems that cannot render parts of the sent message. In particular, it describes an extension to the Delivery Status Notification mechanism. ---------------------------------------------------------------------- 5.2 Critical Content of Internet Mail (draft-ietf-vpim-cc-00.txt) ---------------------------------------------------------------------- It mentions method for sending user Agent (or sender) to indicate body parts that the sender deems critical. "Content-Criticality" entity on each body parts is proposed and there are "critical", "important" and "ignore". For example, receiver rejects message if critical part is undeliverable and notify sender. The issue of backward compatibility is also introduced. ---------------------------------------------------------------------- 5.3 Content Hint for Internet Mail (draft-ietf-vpim-hint-00.txt) ---------------------------------------------------------------------- It mentions method of identifying message as belonging to a (small number of) enumerated message classes, such that it does not require scanning the entire message, etc. Top-level "Content-Hint" header is proposed and there are initial types like "voice-message", "fax-message" and "video-message". There are security considerations. Some concerns are raised and careful discussion is needed. ---------------------------------------------------------------------- 6 ITU issue ---------------------------------------------------------------------- ---------------------------------------------------------------------- 6.1 Letter from Q4/SG8 ---------------------------------------------------------------------- Hiroshi Tamura attended ITU-T Q4/SG8 meeting in June and introduced it. There were the following three items to be discussed at Q4 meeting. - Implementers guide from FAX WG - Request issues - Terminal mode (Refer the following section 6.2.) T.37 will refer implementers guide after draft-ietf-fax-implementers -guide-0x.txt is completed. There were the same requests as the ones WG received last year. a) Enhancement of capability mechanism b) Fax processed status information c) MDN enhancements A question was raised on capability mechanism. In fact there was little discussion in June Q4 meeting. Draft response to ITU-T was introduced. For a), WG's content-negotiation draft is one solution. For b), there is no direct discussion now and fax-specific information may be difficult in MDN/DSN. For c), some clarification is in implementers guide, but may not be enough. Through the introduction, there were comments that PNDN (Partial Non-Delivery Notifications), which VPIM WG discusses, may solve b) and c) partly. (Refer the following section 7.) It was emphasized that any interested people can propose in IETF and IETF is welcome to direct contribution at IETF WGs by ITU people. There was also introduction of WG plan for new SGx meeting in November. It includes notification of WG status, response to request issues and input to newly assigned RFCs. They will be decided in ML until November. ---------------------------------------------------------------------- 6.2 Terminal mode ---------------------------------------------------------------------- Toru Maeda presented terminal mode discussion that is taking place in ITU-T Q4/SG8. The target of terminal mode is easiness to implement and color fax. He commented simple mode and EIFAX as follows. Simple mode is not good for FAX terminal because of no capability exchange and no confirmation. EIFAX is not good for FAX terminal because of complexity for embedded system. ---------------------------------------------------------------------- 7 Confirmation of Milestone and charter ---------------------------------------------------------------------- Claudio Allocchio introduced. WG confirmed milestones and there were no objections. There was also call to all members to get draft reviews quickly. Some members commented that PNDN issue should also be discussed in FAX WG. Whether to take it and add in WG charter will be discussed in ML. AD agrees to it. ---------------------------------------------------------------------- 8 Closing ---------------------------------------------------------------------- Meeting was closed. ----Next_Part(Mon_Aug_21_15:11:38_2000_955)---- From owner-ietf-fax@mail.imc.org Mon Aug 21 06:53: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 GAA29049 for ; Mon, 21 Aug 2000 06:53:42 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA04777 for ietf-fax-bks; Mon, 21 Aug 2000 03:19:13 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA04773 for ; Mon, 21 Aug 2000 03:19:07 -0700 (PDT) Date: Mon, 21 Aug 2000 12:18:37 +0100 To: Dan Wing cc: Harald Alvestrand , ietf-fax@imc.org In-Reply-To: <0008181849030.19999-100000@omega.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Re: Query: Internationalization in addressing components? Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > It's a good idea. No, its a standard violation, if I still remember correctly after vacations! (I need to check the appropriate RFC). > > RFC 2846 (GSTN address elements) defines quite a number of elements that > > have names as their content, including, but not limited to: > > > > - ATTN > > - ORG > > - OFNA > > - STR > > - ADDR > > > > Yet their definition is done without specifying any mechanism for encoding > > non-ASCII characters. They are "inside the e-mail address LHS", i.e. inside the <...> angle brakets which RFC822 specifies for "machine-usable" addresses. RFC822 mailbox = addr-spec ; simple address / phrase route-addr ; name & addr-spec route-addr = "<" [route] addr-spec ">" route = 1#("@" domain) ":" ; path-relative addr-spec = local-part "@" domain ; global address local-part = word *("." word) ; uninterpreted ; case-preserved word = atom / quoted-string atom = 1* quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or ; quoted chars. qtext = , ; => may be folded "\" & CR, and including linear-white-space> CHAR = ; ( 0-177, 0.-127.) > > This makes them useless for specifying a large percentage of the person > > names in the world, for one thing. Exactly... the same problem existing for any "local-part" string. As I'm just back from holidays, I do not remember if and which is the correct mechanism (if existing) to specify a non CHAR character in local-part. If ANY of these mechanisms is specified, the the same rules apply also to the elements (any of them) in RFC 2846... but I'm sure Harald remembers the specification, is any... is it? ciao! Claudio From owner-ietf-fax@mail.imc.org Wed Aug 23 00:25:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22616 for ; Wed, 23 Aug 2000 00:25:07 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA05559 for ietf-fax-bks; Tue, 22 Aug 2000 20:45:53 -0700 (PDT) Received: from smtp2.abac.com (smtp2.abac.com [216.55.128.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA05552 for ; Tue, 22 Aug 2000 20:45:52 -0700 (PDT) From: chris@collegewafer.com Received: from laptop (ip144.boston5.ma.pub-ip.psi.net [38.26.109.144]) by smtp2.abac.com (8.10.1/8.10.1) with SMTP id e7N3xqZ48929 for ietf-fax@imc.org; Tue, 22 Aug 2000 20:59:53 -0700 (PDT) Date: Tue, 22 Aug 2000 20:59:53 -0700 (PDT) To: ietf-fax@imc.org Subject: Si, Ultra-Thin Si (MEMS), GaAs, InP, GaN, PtSi, SOI, Equipment & More... Message-Id: Content-Type: TEXT/PLAIN charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Visit http://www.collegewafer.com for your free quote, or call (800) 713-9375 or Fax (888)-832-0340!!! E-mail us at sales@collegewafer.com All Ultrathin Si wafers polished two sides with TTV < 3 microns for (MEMS) Applications. 4"N(100) 1-10 ohm-cm 10-100 microns polished two sides in Silicon! New Platinum Silicon (PtSi)price posted! 4" SOI Available! Other Wafers: IN STOCK & READY to SHIP Si, GaAs, Ge, InP, InAs, InSb, GaSb, GaN in 1"-12" diameters. Customer supplied GaAs or Ge can be reclaimed or repolished. Equipment Used Vacuum Deposition Equipment Evaporation Systems CHA/Ion Tech Milling Balzers BAK760 and Spitfire and more. Visit us for details! New! Ask for details at sales@collegewafer.com Contact us for your free quote today! Also visit http://www.thecoveredcall.com learn to pick winning stocks using he CANSLIM method of investing with a covered call twist! To REMOVE yourself from this list please visit http://www.collegewafer.com/contact_us/Remove/remove.html MEMS From owner-ietf-fax@mail.imc.org Thu Aug 24 04:12: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 EAA12896 for ; Thu, 24 Aug 2000 04:12:24 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA05904 for ietf-fax-bks; Thu, 24 Aug 2000 00:37:26 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA05900 for ; Thu, 24 Aug 2000 00:37:18 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id QAA04257 for ; Thu, 24 Aug 2000 16:37:43 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id QAA26406 for ; Thu, 24 Aug 2000 16:37:43 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id QAA25192 for ; Thu, 24 Aug 2000 16:37:37 +0900 To: ietf-fax@imc.org Subject: Re: draft minutes of FAX WG at Pittsburgh In-Reply-To: <20000821151221R.tamura@toda.ricoh.co.jp> References: <20000821151221R.tamura@toda.ricoh.co.jp> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000824163920Q.tamura@toda.ricoh.co.jp> Date: Thu, 24 Aug 2000 16:39:20 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 14 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, > Please check it. If there are issues to modify and any other missing > points, please let me know or circulate by Wednesday(Aug 23, ET). > ^^^^^^^^^^^^^^^^^^^^^^^^ There are no comments. Within a few hours, I submit as it is. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Thu Aug 24 05:30:15 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 FAA13370 for ; Thu, 24 Aug 2000 05:30:14 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA08233 for ietf-fax-bks; Thu, 24 Aug 2000 01:57:33 -0700 (PDT) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA08225 for ; Thu, 24 Aug 2000 01:57:31 -0700 (PDT) Received: from HALVESTR-8KCDT.maxware.no (ams-vpdn-client-450.cisco.com [144.254.47.198]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id KAA22856; Thu, 24 Aug 2000 10:57:52 +0200 Message-Id: <4.3.2.7.2.20000824104304.034475d0@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Aug 2000 10:44:30 +0200 To: Claudio Allocchio , Dan Wing From: Harald Alvestrand Subject: Re: Query: Internationalization in addressing components? Cc: ietf-fax@imc.org In-Reply-To: References: <0008181849030.19999-100000@omega.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA08229 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit At 21:18 21/08/2000 +0100, Claudio Allocchio wrote: > > It's a good idea. > >No, its a standard violation, if I still remember correctly after vacations! >(I need to check the appropriate RFC). The user needs to get ÆØÅ and other weird stuff onto the cover page of a fax. The RFC-822 standards insist that the LHS of an email address contain only ASCII characters. We need to resolve the conflict somehow - and I don't find the resolution that says you can put ASCII on the cover page and not ÆØÅ (or Chinese) terribly satisfactory. Harald -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-fax@mail.imc.org Thu Aug 24 05:54: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 FAA13597 for ; Thu, 24 Aug 2000 05:54:44 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA09137 for ietf-fax-bks; Thu, 24 Aug 2000 02:25:06 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA09132 for ; Thu, 24 Aug 2000 02:25:03 -0700 (PDT) Date: Thu, 24 Aug 2000 11:24:55 +0100 To: Harald Alvestrand cc: Claudio Allocchio , Dan Wing , ietf-fax@imc.org In-Reply-To: <4.3.2.7.2.20000824104304.034475d0@127.0.0.1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Re: Query: Internationalization in addressing components? Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id CAA09133 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > The user needs to get ÆØÅ and other weird stuff onto the cover page of a fax. > The RFC-822 standards insist that the LHS of an email address contain only > ASCII characters. > > We need to resolve the conflict somehow - and I don't find the resolution > that says you can put ASCII on the cover page and not ÆØÅ (or Chinese) > terribly satisfactory. Being an "address element" in local-part that's the current only thing which the standard allows. It is NOT completely satisfactory at all... (remember the same problem in X.400 ?) Of course there is work in progress on how to specify and generate full fax cover pages, including not only non-ASCII chars, but anything. However, I'd not suggest a "special solution" just for this case... if we want to allow non-ASCII in local-part, the solution must be global and unique... some work for DRUMS WG? ciao! Claudio From owner-ietf-fax@mail.imc.org Thu Aug 24 06:34: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 GAA14045 for ; Thu, 24 Aug 2000 06:34:16 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA09734 for ietf-fax-bks; Thu, 24 Aug 2000 02:46:41 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA09730 for ; Thu, 24 Aug 2000 02:46:38 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id SAA20086; Thu, 24 Aug 2000 18:46:57 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id SAA12013; Thu, 24 Aug 2000 18:46:54 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id SAA26910; Thu, 24 Aug 2000 18:46:47 +0900 To: minutes@ietf.org, ned.freed@innosoft.com, paf@cisco.com Cc: ietf-fax@imc.org Subject: IETF-FAX WG minutes at Pittsburgh meeting X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Aug_24_18:48:06_2000_955)--" Content-Transfer-Encoding: 7bit Message-Id: <20000824184831C.tamura@toda.ricoh.co.jp> Date: Thu, 24 Aug 2000 18:48:31 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 373 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----Next_Part(Thu_Aug_24_18:48:06_2000_955)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm Hiroshi Tamura, a co-chair of IETF-FAX WG. Attached is the final version of FAX WG minutes at Pittsburgh meeting. With regard to our slides, they are under the specified URL that is described in this minutes, as is the usaul case at our WG. Please accept it. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp ----Next_Part(Thu_Aug_24_18:48:06_2000_955)-- Content-Type: Text/Plain; charset=us-ascii Content-Disposition: attachment; filename="pit_fax-wg_minutes.txt" Content-Transfer-Encoding: 7bit ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Minutes of Internet fax WG (fax) at IETF-48 Pittsburgh ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 9:00 - 11:30, August 2, 2000 Chaired by Claudio Allocchio and Hiroshi Tamura Reported by Graham Klyne and Hiroshi Tamura All slides at the meeting are found at the following URL: http://www.imc.org/ietf-fax/ ---------------------------------------------------------------------- 1 Agenda bashing ---------------------------------------------------------------------- Claudio Allocchio introduced the agenda and it was accepted. ---------------------------------------------------------------------- 2 Status of pending Draft Standards ---------------------------------------------------------------------- It is about update of file format for internet fax (TIFF-FX: RFC 2301). Lloyd McIntyre presented changes to TIFF-FX specification (draft-ietf-fax-tiff-fx-07.txt), which were not formally distributed before the meeting. It was confirmed the changes are purely editorial. Sooner or later, it is announced for the distribution. The version 06 is now under Draft Standard consideration. With these changes, document will go forward in IESG without new last call. ---------------------------------------------------------------------- 3 Targeted for Draft Standard ---------------------------------------------------------------------- ---------------------------------------------------------------------- 3.1 Service ---------------------------------------------------------------------- It is about update of RFC 2305. Kiyoshi Toyoda introduced draft-ietf-fax-service-v2-02.txt, which mentions simple mode fax in internet mail. He presented revisions, which are mainly about non-normative issues. All are the minor editorial changes. It was confirmed that the following three normative references need to move to Draft Standard. - File format (RFC 2301) - Fax address format (RFC 2304) - Format extensions for DSN reports (RFC 1894) ---------------------------------------------------------------------- 3.2 Addressing ---------------------------------------------------------------------- It is about update of RFC 2303 and 2304. Claudio Allocchio introduced draft-ietf-fax-minaddr-v2-01.txt, which mentions minimal GSTN address format in internet mail (RFC 2303). He presented the revisions, which are minor clarification and a correction to ABNF. He also introduced draft-ietf-fax-faxaddr-v2-01.txt, which mentions minimal fax address format in internet mail (RFC 2304). He presented clarification of sub-address format (ITU-T T.33, T.30). Digits are only allowed in it, and '#' and spaces are not allowed. No multiple sub-addresses are allowed. He also introduced RFC 2846 (full addressing), which includes many pre-defined address elements and IANA registration procedures. Kiyoshi Toyoda introduced interworking report about RFC 2304, in order to elevate RFC 2304 to Draft Standard. There are two attendees:TOYOCOM and MGCS. There was a test configuration in which a IFAX device sends document to an offramp gateway through internet and the gateway sends to G3 fax or onramp fax for sub-address. All syntax defined in RFC 2304 were tried for test. The tests satisfied the items of "RFC 2304 interworking configuration Matrix" which has delivered to Fax Connect 2 (http://www.imc.org/imc-faxconnect/). It was confirmed that "formal" report is necessary for request of Draft Standard consideration. ---------------------------------------------------------------------- 4 Internet-Drafts ---------------------------------------------------------------------- ---------------------------------------------------------------------- 4.1 Gateway issue ---------------------------------------------------------------------- Katsuhiko Mimura presented draft-ietf-fax-gateway-protocol-00.txt. It mentions internet fax gateway protocol which has two functions: onramp and offramp. a) Addressing How offramp gateway extract fax number from mail address was introduced. A question was raised about provision for separate identification of country code, to allow receiving system to isolate local dialing part. The standard defines only fully qualified numbers with leading '+', so system should know to expect a country code. Other numbers do not have a defined meaning, and is not appropriate to try and specify behaviour in these cases. Should a receiver be expected to know its own local dialing codes ? Beyond scope of this specification, but implementations needs to take account of these issues. Suggested text is as follows: "Gateway MUST process the mailbox string and convert it to a local dial string according to the local dialing rules". b) File format conversion There is difference between the format of internet fax (TIFF-FX) and the one of GSTN fax. Some conversion is necessary. c) Drop duplications There are the same messages to multiple mail boxes at the same domain. There is some confusion about exactly what this means. There is the following descriptions in the draft: An offramp gateway MUST drop the duplicate mail by confirming whether Message-ID is the same as old one. This is to avoid the duplication of the transmission to same facsimile device over GSTN. It is suggested that the MUST be softened to MAY or SHOULD. Message IDs cannot be guaranteed to be unique (notwithstanding e-mail specification). Also, it is noted that mailing lists can change text without changing message-ID. A question was raised on what is scope of duplicate detection (period of time). d) Automatic retransmission An offramp gateway may automatically retry to send fax data in the case of delivery failure. Questions were raised on whether or not specification to link any retransmissions to the original ones is provided and whether or not retransmissions must be constrained to local legal operating requirements. There was a comment that retransmission specification is not described in ITU-T T.30. It was commented to add a note that retransmission issues may be particularly sensitive, and must be handled with care, because the sending user will not generally be present to deal with any transmission failures. e) Error behaviour Retransmission depends on the contents of errors. It is necessary to to distinguish between T.30/fax "soft" errors (for which retransmission may be appropriate -- e.g. line busy) and "hard" errors (for which retransmission is not appropriate -- e.g. paper out). He suggests this issue should be addressed in another draft. f) Return notice When mail to fax is multicast or broadcast and a delivery error happens, there is an issue about when and how return notice should be done. He suggests this issue should also be addressed in another draft. g) Onramp gateway Onramp gateway functions fax to mail. It is noted that current version is based strictly on simple mode. But, WG may need to decide whether we wish to be restricted to this scope, or whether to address extended /full mode issues from the start. h) Addressing with FAX terminal There is the following description in the draft: An onramp gateway MUST have the function that onramp gateway analyze destination address from address data sent by facsimile device over GSTN. Direct and indirect addressing are discussed. Direct uses given number directly as mailbox name, and uses prefix to select destination domain. Indirect may use number mapping table to select destination mailbox and domain. i) Authorization by DTMF It is necessary that authorization should be done at onramp gateway. GSTN users send UserID and Password to onramp gateway in some ways such as sending DTMF after dialing. j) Next version -01 He promises to announce the next version soon. ---------------------------------------------------------------------- 4.2 Implementers Guide ---------------------------------------------------------------------- Vivian Cancio presented draft-ietf-fax-implementers-guide-02.txt. It is a guide for simple and extended modes. She explained changes to current drafts. There are mainly corrections to the examples (MDN and MTA/ESMTP) and the addition of the case of receiving multiple TIFF attachments, in which it is recommended extended mode recipient returns an error when it is unable to decode any of the attached files. A question was raised on a reasonable mechanism for a sender to determine whether or not an MDN/DSN has been sent *after* the TIFF image has been processed. This information may be useful to automatic status logging systems. ---------------------------------------------------------------------- 4.3 FFPIM ---------------------------------------------------------------------- Graham Klyne presented it. it consists of the following three drafts. a) draft-ietf-fax-ffpim-00.txt b) draft-ietf-fax-timely-delivery-00.txt c) draft-ietf-fax-content-negotiation-02.txt Timely delivery draft will be moved forward, because now DELIVERBY has become RFC 2852. Concerning content negotiation, he explained the overview again. There are a number of technical issues in the negotiation draft that really should have some group discussion on the list, such as use of 'Original -recipient", content-id, cache-control, "content-alternative" header, MDN extensions. They are highlighted in the draft. Further suggestions and comments are invited. For now, it is noted that there may be security concerns (message tracing) if negotiation is allowed with recipients not named by the sender. The distinction between 'definitive' and 'informative' introduces some unintended complexities, and the "sender decides" model for quality decisions seems to be adequate. But it is noted that it should not be done for now. ---------------------------------------------------------------------- 4.4 TIFF-FX extension issue ---------------------------------------------------------------------- Lloyd McIntyre presented it. It is not formally distributed. But it is draft-mcintyre-fax-tiff-fx-extension-00.txt in http://www.imc.org/ draft-mcintyre-fax-tiff-fx-extension. From the contents of the Adelaide meeting in March, MRC:multi-strip background and foreground layers and Annotation are deleted, because they are immature. They are candidate for future draft. Therefore, the extension includes new field values and/or relaxed constraints (higher resolutions and MRC with more than 3 MRC layers) and new fields and/or profiles(more than one profile within document and JBIG2). He presented these new field values like 600x600dpi, relaxed constrains like more than 3 MRC layers, JBIG2 etc. He also explained overview of relation of changes to current TIFF-FX profiles. It was confirmed that the enhancements require new tags to be approved by Adobe, for which a formal WG request may be required. ---------------------------------------------------------------------- 5 Issue from VPIM WG ---------------------------------------------------------------------- Glenn Parsons, who is a co-chair of VPIM WG, introduced the internet fax related issues discussed in VPIM WG. ---------------------------------------------------------------------- 5.1 Partial Non-Delivery Notifications (draft-ietf-vpim-pndn-00.txt) ---------------------------------------------------------------------- It describes the interaction between systems sending multipart Internet main to systems that cannot render parts of the sent message. In particular, it describes an extension to the Delivery Status Notification mechanism. ---------------------------------------------------------------------- 5.2 Critical Content of Internet Mail (draft-ietf-vpim-cc-00.txt) ---------------------------------------------------------------------- It mentions method for sending user Agent (or sender) to indicate body parts that the sender deems critical. "Content-Criticality" entity on each body parts is proposed and there are "critical", "important" and "ignore". For example, receiver rejects message if critical part is undeliverable and notify sender. The issue of backward compatibility is also introduced. ---------------------------------------------------------------------- 5.3 Content Hint for Internet Mail (draft-ietf-vpim-hint-00.txt) ---------------------------------------------------------------------- It mentions method of identifying message as belonging to a (small number of) enumerated message classes, such that it does not require scanning the entire message, etc. Top-level "Content-Hint" header is proposed and there are initial types like "voice-message", "fax-message" and "video-message". There are security considerations. Some concerns are raised and careful discussion is needed. ---------------------------------------------------------------------- 6 ITU issue ---------------------------------------------------------------------- ---------------------------------------------------------------------- 6.1 Letter from Q4/SG8 ---------------------------------------------------------------------- Hiroshi Tamura attended ITU-T Q4/SG8 meeting in June and introduced it. There were the following three items to be discussed at Q4 meeting. - Implementers guide from FAX WG - Request issues - Terminal mode (Refer the following section 6.2.) T.37 will refer implementers guide after draft-ietf-fax-implementers -guide-0x.txt is completed. There were the same requests as the ones WG received last year. a) Enhancement of capability mechanism b) Fax processed status information c) MDN enhancements A question was raised on capability mechanism. In fact there was little discussion in June Q4 meeting. Draft response to ITU-T was introduced. For a), WG's content-negotiation draft is one solution. For b), there is no direct discussion now and fax-specific information may be difficult in MDN/DSN. For c), some clarification is in implementers guide, but may not be enough. Through the introduction, there were comments that PNDN (Partial Non-Delivery Notifications), which VPIM WG discusses, may solve b) and c) partly. (Refer the following section 7.) It was emphasized that any interested people can propose in IETF and IETF is welcome to direct contribution at IETF WGs by ITU people. There was also introduction of WG plan for new SGx meeting in November. It includes notification of WG status, response to request issues and input to newly assigned RFCs. They will be decided in ML until November. ---------------------------------------------------------------------- 6.2 Terminal mode ---------------------------------------------------------------------- Toru Maeda presented terminal mode discussion that is taking place in ITU-T Q4/SG8. The target of terminal mode is easiness to implement and color fax. He commented simple mode and EIFAX as follows. Simple mode is not good for FAX terminal because of no capability exchange and no confirmation. EIFAX is not good for FAX terminal because of complexity for embedded system. ---------------------------------------------------------------------- 7 Confirmation of Milestone and charter ---------------------------------------------------------------------- Claudio Allocchio introduced. WG confirmed milestones and there were no objections. There was also call to all members to get draft reviews quickly. Some members commented that PNDN issue should also be discussed in FAX WG. Whether to take it and add in WG charter will be discussed in ML. AD agrees to it. ---------------------------------------------------------------------- 8 Closing ---------------------------------------------------------------------- Meeting was closed. ----Next_Part(Thu_Aug_24_18:48:06_2000_955)---- From owner-ietf-fax@mail.imc.org Thu Aug 24 09:42:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16978 for ; Thu, 24 Aug 2000 09:42:57 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA17019 for ietf-fax-bks; Thu, 24 Aug 2000 06:08:30 -0700 (PDT) Received: from typhoon.mail.pipex.net (typhoon.mail.pipex.net [158.43.128.27]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA17015 for ; Thu, 24 Aug 2000 06:08:29 -0700 (PDT) Received: (qmail 11611 invoked from network); 24 Aug 2000 13:08:56 -0000 Received: from userc993.uk.uudial.com (HELO GK-VAIO.Dial.pipex.com) (194.69.109.197) by smtp.dial.pipex.com with SMTP; 24 Aug 2000 13:08:56 -0000 Message-Id: <4.3.2.7.2.20000824101320.00acac90@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Aug 2000 11:00:49 +0100 To: Harald Alvestrand From: Graham Klyne Subject: Re: Query: Internationalization in addressing components? Cc: ietf-fax@imc.org In-Reply-To: <4.3.2.7.2.20000819093136.02a23ef8@127.0.0.1> References: <0008181849030.19999-100000@omega.cisco.com> <4.3.2.7.2.20000815135117.01df22a0@nordic.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:33 AM 8/19/00 -0700, Harald Alvestrand wrote: >At 18:52 18/08/2000 -0700, Dan Wing wrote: >>It's a good idea. >> >>But how would a receiver decide if the following three forms are supposed >>to be equal? >> >> /ATTN==?ISO-8859-1?Q?Patrik.F=E4ltstr=F6m?= >> /ATTN==?US-ASCII?Q?Patrik.Faltstrom?= >> /ATTN=Patrik.Faltstrom >> >>Perhaps we could just require that text after ATTN, ORG, OFNA, STR, and >>ADDR shouldn't be matched exactly? > >The most common reason for ATTN is to print on fax cover pages; there is >no standard way to transfer the ATTN information across a T.4/T.20 fax call. >So the important thing is to make sure the offramp (fax sender) >understands the character set; exact matching isn't that important. > >IMHO. I think this opens a can of worms about just how far it is sensible to take the RFC2403/2504/et.seq. addressing framework. When used as part of an e-mail local address, the normal expectation is that exact matching is required to select a mailbox. But as interpretation is defined to be under control of the receiving server, some flexibility is theoretically possible. Personally, I think that putting this kind of non-addressing information in an e-mail address is going to lead to problems. I think there has been a desire to carry all of X.400 addressing elements into some kind of e-mail format. I would say that it may be reasonable to map all the _addressing_ elements in this way, but that non-addressing elements should be treated in some other way. PS: As an additional point, I think that RFC 204x explicitly disallows the use of =?...?= encoding forms in address fields. #g -- ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Thu Aug 24 17:40: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 RAA24325 for ; Thu, 24 Aug 2000 17:40:25 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA04899 for ietf-fax-bks; Thu, 24 Aug 2000 12:48:04 -0700 (PDT) Received: from ananke.eastgw.xerox.com (root@ananke.xerox.com [208.140.33.24]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04895 for ; Thu, 24 Aug 2000 12:48:02 -0700 (PDT) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by ananke.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id PAA29379 for ; Thu, 24 Aug 2000 15:48:28 -0400 (EDT) Received: from mercury.adoc.xerox.com (mercury [13.242.100.20]) by godzilla.ADOC.xerox.com (8.8.8+Sun/8.8.8/ADOC-HUB-1.7) with ESMTP id MAA00777 for ; Thu, 24 Aug 2000 12:48:26 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2448.0) id ; Thu, 24 Aug 2000 12:48:26 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE092C8931@mercury.ADOC.xerox.com> From: "Cancio, Vivian" To: ietf-fax@imc.org Subject: FAX= in ORCPT Date: Thu, 24 Aug 2000 12:48:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C00E04.4458C8C0" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C00E04.4458C8C0 Content-Type: text/plain; charset="iso-8859-1" It appears that we need to add some clarification in the Implementers Guide with regards to the text in Section 2.3 of RFC 2298 and Section 5 of RFC 1891. See below. I was brought to my attention that the interpretation of this text and the representation of "=" (as in FAX=) in the ORCPT parameter might be an issue. Is there any doubt that "FAX=" should be represented in the ORCPT parameter as FAX+3D? Vivian ------_=_NextPart_000_01C00E04.4458C8C0 Content-Type: text/plain; name="RFC2298Extract.txt" Content-Disposition: attachment; filename="RFC2298Extract.txt" RFC 2298 An Extensible Message Format for Message Disposition Notifications 2.3 The Original-Recipient Header Since electronic mail addresses may be rewritten while the message is in transit, it is useful for the original recipient address to be made available by the delivering MTA. The delivering MTA may be able to obtain this information from the ORCPT parameter of the SMTP RCPT TO command, as defined in RFC 1891 [8]. If this information is available, the delivering MTA SHOULD insert an Original-Recipient header at the beginning of the message (along with the Return-Path header). The delivering MTA MAY delete any other Original-Recipient headers that occur in the message. The syntax of this header, using the ABNF of RFC 822 [2], is as follows original-recipient-header = "Original-Recipient" ":" address-type ";" generic-address ------_=_NextPart_000_01C00E04.4458C8C0 Content-Type: text/plain; name="RFC1891Extract.txt" Content-Disposition: attachment; filename="RFC1891Extract.txt" RFC 1891 SMTP Service Extension for Delivery Status Notifications 5. Additional parameters for RCPT and MAIL commands The extended RCPT and MAIL commands are issued by a client when it wishes to request a DSN from the server, under certain conditions, for a particular recipient. The extended RCPT and MAIL commands are identical to the RCPT and MAIL commands defined in [1], except that one or more of the following parameters appear after the sender or recipient address, respectively. The general syntax for extended SMTP commands is defined in [4]. NOTE: Although RFC 822 ABNF is used to describe the syntax of these parameters, they are not, in the language of that document, "structured field bodies". Therefore, while parentheses MAY appear within an emstp-value, they are not recognized as comment delimiters. The syntax for "esmtp-value" in [4] does not allow SP, "=", control characters, or characters outside the traditional ASCII range of 1- 127 decimal to be transmitted in an esmtp-value. Because the ENVID and ORCPT parameters may need to convey values outside this range, the esmtp-values for these parameters are encoded as "xtext". "xtext" is formally defined as follows: xtext = *( xchar / hexchar ) xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, except for "+" and "=". ; "hexchar"s are intended to encode octets that cannot appear ; as ASCII characters within an esmtp-value. hexchar = ASCII "+" immediately followed by two upper case hexadecimal digits When encoding an octet sequence as xtext: + Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=", MAY be encoded as itself. (A CHAR in this range MAY instead be encoded as a "hexchar", at the implementor's discretion.) + ASCII CHARs that fall outside the range above must be encoded as "hexchar". ------_=_NextPart_000_01C00E04.4458C8C0 Content-Type: text/plain; name="RFC1651Extract.txt" Content-Disposition: attachment; filename="RFC1651Extract.txt" RFC 1651 SMTP Service Extensions 6. MAIL FROM and RCPT TO Parameters It is recognized that several of the extensions planned for SMTP will make use of additional parameters associated with the MAIL FROM and RCPT TO command. The syntax for these commands, again using the ABNF notation of [2] as well as underlying definitions from [1], is: esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter) esmtp-parameter ::= esmtp-keyword ["=" esmtp-value] esmtp-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") ; syntax and values depend on esmtp-keyword esmtp-value ::= 1*") / ("RCPT TO:<" forward-path ">") All esmtp-keyword values must be registered as part of the IANA registration process described above. This definition only provides the framework for future extension; no extended MAIL FROM or RCPT TO parameters are defined by this RFC. ------_=_NextPart_000_01C00E04.4458C8C0-- From owner-ietf-fax@mail.imc.org Thu Aug 24 20:19:55 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 UAA25670 for ; Thu, 24 Aug 2000 20:19:55 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA09273 for ietf-fax-bks; Thu, 24 Aug 2000 16:51:54 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09267 for ; Thu, 24 Aug 2000 16:51:39 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id IAA25167; Fri, 25 Aug 2000 08:45:20 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id IAA20352; Fri, 25 Aug 2000 08:45:19 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id IAA03338; Fri, 25 Aug 2000 08:45:17 +0900 To: Vivian.Cancio@pahv.xerox.com Cc: ietf-fax@imc.org Subject: Re: FAX= in ORCPT In-Reply-To: <51B8ABCE456FD111899900805F6FD6EE092C8931@mercury.ADOC.xerox.com> References: <51B8ABCE456FD111899900805F6FD6EE092C8931@mercury.ADOC.xerox.com> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000825084658N.tamura@toda.ricoh.co.jp> Date: Fri, 25 Aug 2000 08:46:58 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 30 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yes, clarification is better. > It appears that we need to add some clarification in the Implementers Guide > with regards to the text in Section 2.3 of RFC 2298 and Section 5 of RFC > 1891. See below. OK. A simple question. Why does this rule apply to ONLY optional header and additional parameters? I hope this question does not cause repetitive discussion in the past. > I was brought to my attention that the interpretation of this text and the > representation of "=" (as in FAX=) in the ORCPT parameter might be an issue. > > Is there any doubt that "FAX=" should be represented in the ORCPT parameter > as FAX+3D? According to the rule, it is right. But, ..... We have an interworking report on RFC2304. Toyoda-san, did you use ORCPT in the test? Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Fri Aug 25 01:27:22 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 BAA03002 for ; Fri, 25 Aug 2000 01:27:22 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA02507 for ietf-fax-bks; Thu, 24 Aug 2000 21:53:04 -0700 (PDT) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA02503 for ; Thu, 24 Aug 2000 21:53:02 -0700 (PDT) Received: by bulls.mei.co.jp (8.11.0/3.7W) with ESMTP id e7P4niT08151; Fri, 25 Aug 2000 13:49:44 +0900 (JST) Received: by dodgers.mei.co.jp (8.9.1/3.7W) with SMTP id NAA09948; Fri, 25 Aug 2000 13:49:43 +0900 (JST) Received: from [133.185.137.6] by m-bb.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 25 Aug 2000 04:49:44 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0.mgcs.mei.co.jp (8.9.3/3.7W-HUB) with ESMTP id NAA25949; Fri, 25 Aug 2000 13:49:43 +0900 (JST) Received: from mlsv2.rdmg.mgcs.mei.co.jp by mlsv1.mgcs.mei.co.jp (8.9.3/3.7W-MGCS) with ESMTP id NAA05197; Fri, 25 Aug 2000 13:49:23 +0900 (JST) Received: from d23n59.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.9.3/3.7W-RDMG) with SMTP id NAA29841; Fri, 25 Aug 2000 13:49:41 +0900 (JST) Message-Id: <200008250453.AA00622@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Fri, 25 Aug 2000 13:53:44 +0900 To: Hiroshi Tamura Cc: Vivian.Cancio@pahv.xerox.com, ietf-fax@imc.org Subject: Re: FAX= in ORCPT In-Reply-To: <20000825084658N.tamura@toda.ricoh.co.jp> References: <20000825084658N.tamura@toda.ricoh.co.jp> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hiroshi Tamura wrote: >> I was brought to my attention that the interpretation of this text and the >> representation of "=" (as in FAX=) in the ORCPT parameter might be an issue. >> >> Is there any doubt that "FAX=" should be represented in the ORCPT parameter >> as FAX+3D? > >According to the rule, it is right. But, ..... > >We have an interworking report on RFC2304. >Toyoda-san, >did you use ORCPT in the test? > We didn't use ORCPT parameter in our test. I think "FAX=" must be encoded according to RFC1891 if you use ORCPT parameter. But, I think it isn't issue because "=" can appear in any e-mail address. Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Fri Aug 25 04:50:00 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 EAA14469 for ; Fri, 25 Aug 2000 04:49:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA15829 for ietf-fax-bks; Fri, 25 Aug 2000 01:14:47 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA15822 for ; Fri, 25 Aug 2000 01:14:44 -0700 (PDT) Date: Fri, 25 Aug 2000 10:12:18 +0100 To: "Toyoda, Kiyoshi" cc: Hiroshi Tamura , Vivian.Cancio@pahv.xerox.com, ietf-fax@imc.org In-Reply-To: <200008250453.AA00622@d23n59.rdmg.mgcs.mei.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Re: FAX= in ORCPT Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > We didn't use ORCPT parameter in our test. > > I think "FAX=" must be encoded according to RFC1891 if you use ORCPT > parameter. But, I think it isn't issue because "=" can appear in any > e-mail address. Correct... As we already discussed privately, there is a need for general clarification on the issue. In realy the '=' ASCII char is in use 'as is', in local-part (see RFC822) since years and is in production also since years: See the whole MIXER specification (RFC 2156) and all the MIXER existing and interworking implementations which encode X.400 addresses as /C=it/A=garr/P=garr/S=Allocchio/G=Claudio/@cosine-gw.infn.it I'll be back with a detailed "clarification proposal" in the next message! regards, Claudio From owner-ietf-fax@mail.imc.org Fri Aug 25 06:43:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15348 for ; Fri, 25 Aug 2000 06:43:45 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA23450 for ietf-fax-bks; Fri, 25 Aug 2000 03:07:49 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA23445 for ; Fri, 25 Aug 2000 03:07:47 -0700 (PDT) Date: Fri, 25 Aug 2000 12:05:34 +0100 To: "Cancio, Vivian" cc: ietf-fax@imc.org In-Reply-To: <51B8ABCE456FD111899900805F6FD6EE092C8931@mercury.ADOC.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Re: FAX= in ORCPT Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallo Vivian and all, > It appears that we need to add some clarification in the Implementers Guide > with regards to the text in Section 2.3 of RFC 2298 and Section 5 of RFC > 1891. See below. > I was brought to my attention that the interpretation of this text and the > representation of "=" (as in FAX=) in the ORCPT parameter might be an issue. I will try in the following to clarify the question. As we all know, there are ENVELOPE (SMTP - RFC821) and HEADER (RFC822) fields to deal with. The RFC822 header fields for "originator" (From:, Sender:) and "recipient" (To:, Cc:, Bcc:) and similar fields (Reply-To:,...) contain the definition of the machine usable address, where local-part is defined as allowing the '=' character. The RFC821 'MAIL FROM' and 'RCPT TO' fields allow also the '=' char inside the and elements. The RFC1891 ORCPT paramter in ESMTP, being a parameter made by esmtp-parameter ::= esmtp-keyword ["=" esmtp-value] MUST NOT contain the '=' sign in esmtp-value. I think a written example can simplify anything. ESMTP Envelope commands: MAIL FROM: RCPT TO: ORCPT=FAX+3D+2B290408565@fxmail.com Thus the possible text for the implementers guide could be: ------------------------- begin ------------------------------------ The GSTN addresses in e-mail addresses specifications (currently RFC2303, RFC2304 and RFC2846) require the use of the "=" and "+" characters inside the local-part (see RFC822) and forward-path and reverse-path (see RFC821) of the address. In these fields the "=" and "+" characters are allowed and thus they MUST NOT be encoded in any way. Also other message headers fields extensions (like Original-Recipient, see RFC2298) allows these characters which thus MUST NOT be encoded. However GSTN addresses can also appear in other fields, and in particular inside ESMTP parameters as esmtp-value (see RFC1651); the ORCPT parameter (see RFC1891) is one of such cases. When the "=" and "+" characters in GSTN addresses appear as esmtp-value, they MUST be encoded as hexchar (see RFC1891). In particular, the same GSTN address could require different behaviour inside the same ESMTP command line: RCPT TO: ORCPT=FAX+3D+2B290408565@fxmail.com ------------------------- end ------------------------------------ regards, Claudio From owner-ietf-fax@mail.imc.org Wed Aug 30 05:14:24 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 FAA22690 for ; Wed, 30 Aug 2000 05:14:24 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA02970 for ietf-fax-bks; Wed, 30 Aug 2000 01:12:45 -0700 (PDT) Received: from sendflowersamerica.com ([206.168.43.194]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA01618; Wed, 30 Aug 2000 01:00:01 -0700 (PDT) From: sfaquestions@sendflowersamerica.com Subject: FlowerFunds - Fund Raising Program Date: Wed, 30 Aug 2000 01:32:17 Message-Id: <620.108063.29555@sendflowersamerica.com> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: SendFlowersAmerica is proud to introduce FlowerFunds-- This unique new concept will provide an income flow for your organization for years to come. Your organization is invited to explore the possibilities of participating in FlowerFunds. $FlowerFunds is an individualized fund raising program for non-profit organizations and schools. $FlowerFunds are cash rebates that are paid to your organization each and every time an order is placed by your members and supporters. $The best part is that it costs your organization nothing to participate!! How it works: 1. When your members and supporters order flowers or gifts through sendflowersamerica they determine the price they want to pay; be it $30, $40, $50 or $1000. Since your members and supporters determine the price, they all can participate in this program. 2. Your organization receives 20% of the purchase price of the order. Say a husband buys his wife a $50 bouquet. Your organization will receive a $10 cash rebate. Nice. This program never ends. Each and every time there is an order placed by your memebers and supporters, your organization will receive the 20% cash rebate. That's a lot of FlowerFunds, and your organization stands to benefit from a findraiser unlike any other fundraiser. For more information call 1 800 SEND 123 or http://www.sendflowersamerica.com Imagine earning money for your organization by making someone smile :-) From owner-ietf-fax@mail.imc.org Thu Aug 31 06:20:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02817 for ; Thu, 31 Aug 2000 06:20:46 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA06291 for ietf-fax-bks; Thu, 31 Aug 2000 02:37:04 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA06287 for ; Thu, 31 Aug 2000 02:37:02 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id SAA18897; Thu, 31 Aug 2000 18:31:17 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id SAA19933; Thu, 31 Aug 2000 18:31:15 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id SAA15296; Thu, 31 Aug 2000 18:31:09 +0900 To: Claudio.Allocchio@elettra.trieste.it Cc: Vivian.Cancio@pahv.xerox.com, ietf-fax@imc.org Subject: Re: FAX= in ORCPT In-Reply-To: References: <51B8ABCE456FD111899900805F6FD6EE092C8931@mercury.ADOC.xerox.com> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000831183305M.tamura@toda.ricoh.co.jp> Date: Thu, 31 Aug 2000 18:33:05 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 35 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Small correction. > ------------------------- begin ------------------------------------ > > The GSTN addresses in e-mail addresses specifications (currently RFC2303, > RFC2304 and RFC2846) require the use of the "=" and "+" characters inside > the local-part (see RFC822) and forward-path and reverse-path (see RFC821) > of the address. In these fields the "=" and "+" characters are allowed and > thus they MUST NOT be encoded in any way. Also other message headers fields > extensions (like Original-Recipient, see RFC2298) allows these characters > which thus MUST NOT be encoded. > > However GSTN addresses can also appear in other fields, and in particular > inside ESMTP parameters as esmtp-value (see RFC1651); the ORCPT parameter ^^^^ 1869 RFC 1651 is obsolete. > (see RFC1891) is one of such cases. When the "=" and "+" characters in > GSTN addresses appear as esmtp-value, they MUST be encoded as hexchar > (see RFC1891). > > In particular, the same GSTN address could require different behaviour > inside the same ESMTP command line: > > RCPT TO: ORCPT=FAX+3D+2B290408565@fxmail.com > > ------------------------- end ------------------------------------ Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Thu Aug 31 08:52: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 IAA05211 for ; Thu, 31 Aug 2000 08:52:56 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA17171 for ietf-fax-bks; Thu, 31 Aug 2000 05:23:32 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA17163 for ; Thu, 31 Aug 2000 05:23:29 -0700 (PDT) Date: Thu, 31 Aug 2000 14:21:23 +0100 To: Hiroshi Tamura cc: Vivian.Cancio@pahv.xerox.com, ietf-fax@imc.org In-Reply-To: <20000831183305M.tamura@toda.ricoh.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Re: FAX= in ORCPT Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Small correction. yes, you're right! thank you! Claudio > > inside ESMTP parameters as esmtp-value (see RFC1651); the ORCPT parameter > ^^^^ > 1869 > > RFC 1651 is obsolete.