ITU-T T 37 AMD 1-1999 Procedures for the Transfer of Facsimile Data Via Store-and-Foward on the Internet Amendment 1 Full Mode Series T Terminals for Telematic Services (Study Grou.pdf

《ITU-T T 37 AMD 1-1999 Procedures for the Transfer of Facsimile Data Via Store-and-Foward on the Internet Amendment 1 Full Mode Series T Terminals for Telematic Services (Study Grou.pdf》由会员分享，可在线阅读，更多相关《ITU-T T 37 AMD 1-1999 Procedures for the Transfer of Facsimile Data Via Store-and-Foward on the Internet Amendment 1 Full Mode Series T Terminals for Telematic Services (Study Grou.pdf（63页珍藏版）》请在麦多课文档分享上搜索。

1、INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU T.37 Amendment 1 (O 9/9 9) SERIES T: TERMINALS FOR TELEMATIC SERVICES Procedures for the transfer of facsimile data via store-and-forward on the Internet Amendment 1: Full Mode ITU-T Recommendation T.37 - Ame

2、ndment 1 (Previously CCITT Recommendation) ITU-T T-SERIES RECOMMENDATIONS TERMINALS FOR TELEMATIC SERVICES For further details, please refe. to ITU-T List of Recommendations. ITU-T RECOMMENDATION T.37 PROCEDURES FOR THE TRANSFER OF FACSIMILE DATA VIA STORE-AND-FORWARD ON THE INTERNET AMENDMENT 1 Fui

3、i Mode Summary This amendment adds support for the Full Mode of Internet fax to Recommendation T.37. The additional functionality includes support for the transmission and reception of additional TIFF image formats, capabilities exchange and acknowledgement of receipt. Source Amendment 1 to ITU-T Re

4、commendation T.37 was prepared by ITU-T Study Group 8 (1997-2000) and was approved under the WTSC Resolution No. 1 procedure on 24 September 1999. Recommendation T.37/Amd.l (09/99) i FOREWORD ITU (International Telecommunication Union) is the United Nations Specialized Agency in the field of telecom

5、muni- cations. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of the ITU. The ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World

6、 Telecommunication Standardization Conference (WTSC), which meets every four years, establishes the topics for study by the ITU-T Study Groups which, in their turn, produce Recommendations on these topics. The approval of Recommendations by the Members of the ITU-T is covered by the procedure laid d

7、own in WTSC Resolution No. 1. In some areas of information technology which fall within ITU-T?s purview, the necessary standards are prepared on a collaborative basis with IS0 and IEC. NOTE In this Recommendation, the expression ?Administrations? is used for conciseness to indicate both a telecommun

8、ication administration and a recognized operating agency. INTELLECTUAL PROPERTY RIGHTS The ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. The ITU takes no position concerning the evidence

9、, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, the ITU had received notice of intellectual property, protected by patents, which may b

10、e required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database. O ITU 2000 All rights reserved. No part of this publication may be reproduced or utilized in any fo

11、rm or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing fiom the ITU. 11 Recommendation T.37/Amd.l (09/99) CONTENTS Page 1) Clause 3 . 1 2) Subclause 6.2 1 3) Appendix I . 2 4) New Appendix III . 5 5) New Appendix IV . 5 Recommendation T.37/A

12、md.l (09/99) . 111 Recommendation T.37 PROCEDURES FOR THE TRANSFER OF FACSIMILE DATA VIA STORE-AND-FORWARD ON THE INTERNET AMENDMENT 1 Full Mode (Geneva, 1999) 1) Clause 3 Delete the following references: - CCITT Recommendation T.6 (1988), Facsimile coding schemes and coding control functions for Gr

13、oup 4 facsimile apparatus. - RFC 1725, Post OfJice Protocol - Version 3. Add the following references and Note: - - - - - - - NOTE - Embedded references within RFCs referenced in this Recommendation, which are described as “work in progress“, are informative only and not normative. RFC 1869, SMTP Se

14、rvice Extensions. RFC 1939, Post OfJice Protocol - Version 3. RFC 2060, Internet Message Access Protocol - Version 4revl. RFC 2298, An Extensible Message Format for Message Disposition Notijcations. RFC 2532, Extended Facsimile Using Internet Mail. RFC 2530, Indicating Supported Media Features Using

15、 Extensions to DSN and MDN. RFC 253 1, Content Feature Schema for Internet Fax. 2) Subclause 6.2 Amend subclause 6.2 to read: 6.2 Full Mode Full Mode supports the transfer of image data, capabilities exchange and acknowledgement of receipt, per the requirements of Recommendation F. 185. 6.2.1 Proced

16、ures for Full Mode Procedures for Full Mode are defined in RFC 2532, unless stated otherwise in Table 2. A functional summary and related references for Full Mode are included in the table. Recommendation T.37/Amd.l (09/99) 1 Table 2/T.37 - Functional summary of procedures for Full Mode Acknowledgem

17、ent of receipt Capabilities exchange Addressing Delivery Confirmation: RFC 1891, Delivery Status Notification (DSN) Processing Confirmation: RFC 2298, Message Disposition Notification (MDN) Capabilities Format: RFC 253 1 Capabilities Mechanism: RFC 2530 Procedures: RFC 2305 section 3 Email: RFC822 O

18、fiamp: RFC 2303, RFC 2304 Transport Mailbox access Image format I TIFFProfiles: RFC2301 ESMTP: RFC 1869 POP3: RFC 1939 IMAP4: RFC2060 I I I Provide notice in case of relay problems Provide a return address in the SMTP mail from envelope header NOTE - The requirement for onramp and ofiamp gateways to

19、 support G4 facsimile terminals is for further study. RFC 2305 0 2.3.1 RFC 2305 0 2.3.1 3) Appendix I Use Base 64 encoding for image data Be able to recognize and process the feature tags as defined in RFC 253 1 when reviewing the capabilities presented by a potential recipient Add a new subclause 1

20、.2: RFC 2532 0 3 (Note 2) 1.2 Fuii Mode implementation requirements Optional Table I.2/T.37 - Implementation requirements for Full Mode Use other TIFF Profiles if it has prior knowledge that such profiles are supported by the receiver Provide notice on receipt of DSN or other notifications RFC 2305

21、0 4 RFC 1894 (Note 3) Sender Required I Send image data as a single MIME multi-page RFC 2301 file I RFC 2305 0 2.2.3 I I I I Send a message containing both minimum subset of TIFF and a higher quality TIFF using multipadalternative Manually override the default setting RFC 2532 0 3 RFC 2532 0 3.1 I I

22、 I Access directory structure of recipient capabilities Use any of the TIFF Profiles defined in RFC 2301 when sending to a recipient with the corresponding capabilities based on an MDNDSN capability response Request Delivery Status Notification, if the sender desires delivery confirmation RFC 2532 0

23、 2.1.1 I (Note 3) RFC 2532 0 3.2 RFC 2532 0 3 (Notes 1,2 and 4) I l I I I Request Message Disposition Notification, if the sender desires processing confirmation RFC 2532 0 2.1.2 I (Note 3) Strongly I Include Message-ID recommended I RFc 2305 2.2.1 I I I I I I I I RFC 2532 0 3.3 (Notes 1,2 and 4) I

24、Request a positive DSN and an MDN, if DSNMDN capability response is desired I l I I 2 Recommendation T.37/Amd.l (09/99) Table I.2/T.37 (continued) I I I I Receiver I I I I I Required Be MIME compliant except that it is not required to offer to place a MIME attachment in a file and may print a receiv

25、ed file rather than display RFC 2305 4 2.2.2 I I I I l I I I I I Be capable of processing multiple MIME RFC 2301 Profile S image files within a single message RFC 2305 4 2.2.4 Implement Message Disposition Notification Indicate supported media features in DSN and/or MDN messages per RFC 2530 RFC 253

26、2 4 2.2 (Notes 1,2 and 4) RFC 2532 4 2.2 Provide notice in case of reception or processing problems Configurable to silently ignore a request for MDN Not generate an unsolicited MDN to indicate successful processing RFC 2305 4 2.3.2 I (Note 3) RFC 2532 4 2.2.1 RFC 2532 4 2.2.1 Possible for an operat

27、or to disable automatic MDN responses Not generate DSN when using POP3 and MAP4 RFC 2532 4 2.2.1 RFC 2532 4 2.2.2 Required Support for DSN RFC 2532 4 2.3.1 (Note 5) I I Comply with the relevant ITU Recommendations relating to facsimile transmission Attempt to relay authorized Email to the correspond

28、ing G3 facsimile terminals Strongly recommended code 5.6.1 Ifthe MTA determines the message cannot be processed, reject the message with a status RFC 2530 I (Note 3) T.30 RFC 2305 4 3.2 I Optional I Be capable of processing any TIFF Profiles I RFC 230544 I Strongly recommended I I I Ensure that loca

29、l legal requirements relating to facsimile transmissions are met Use DSN for delivery failure notification RFC 2305 4 2.3.1 RFC 1894 (Note 3) I I Automated system be configurable to always respond to MDN request I RFC 2532 4 2.2.1 I Optional I Sender infrastructure I Translate image data into a form

30、at acceptable by the receiving G3 facsimile terminal Use a mailbox access protocol when serving a single mail recipient RFC 2305 4 2.1.2 RFC 2305 4 2.1.3 I support for DSN Required RFC 2532 4 2.3.2 I (Note 5) I Offramp gateway (When implemented) I I Required I Be SMTP compliant I RFCO821 I I I I I P

31、rovide delivery failure notification Be able to process PSTN/FAX Email addresses RFC 1894, RFC 2305 4 2.3.1 (Note 3) RFC 2303, RFC 2304 I I I I I I Use an approved mailbox access protocol when serving multiple users I RFC 2305 4 2.1.3 Recommendation T.37/Amd.l (09/99) 3 Table I.2/T.37 (end) NOTE 1 -

32、 Typical Full Mode implementation includes capability exchange. The available method for eliciting a capability response is by requesting an MDN or DSN. In response, recipient should provide an indication of capabilities using DSN/MDN extensions per RFC 2530 extension. The detailed method of request

33、ing MDNDSN and use of other capabilities request and indication methods are for further study. NOTE 2 - For the typical Full Mode implementation, the DSN or MDN that is returned should contain information describing the recipients capabilities. The sender should use this information for subsequent c

34、ommunications with that recipient. For example, a sender may use any of the TIFF Profiles defined in RFC 2301 when sending to a recipient with the corresponding capabilities based on an MDNDSN capability response. NOTE 3 - For the typical Full Mode implementation, delivery confirmation and processin

35、g confirmation are available using DSN and MDN. Clarification of MDN processing is for further study. Inclusion of additional data such as total page number and error page number in MDN and DSN messages is for further study. NOTE 4 - Some implementers may wish to add private extensions to the standa

36、rd Full Mode implementation. For example, venders could find company-specific MIME types and X Email headers to help implement specific applications. NOTE 5 - Per RFC 2532, DSN support is required within the sender and receiver infrastructure. Full Mode terminals may still operate in situations wher

37、e some MTAs in the mail relay path do not support DSN. Delivery confirmation via DSN for the final destination will not be provided in this case. However, processing confirmation via MDN may still be possible. 4 Recommendation T.37/Amd.l (09/99) 4) New Appendix III Add a new Appendix III: Appendix I

38、II Full Mode RFC references chart This appendix provides a chart of relationships among the Internet standards that are used for achieving T.37 Full Mode functionality. EIFAX RFC 2532 4 4 TIFF for facsimile RFC 2301 routing Reporting RFC 2530 RFC 974 RFC 2305 RFC Mapping informational Media featu re

39、s RFC 2534 Registration RFC 2506 I BCP SMTP server extension I: RFC 2034 El RFC 2298 mechanism RFC 1891 I I . I format RFC 1894 Multipartl Status RFC 1892 codes RFC 1893 T0828420-98/601 5) New Appendix IV Add a new Appendix IV: Appendix IV TIFF-FX (RFC 2301) coding examples for profiles beyond Profi

40、le S This appendix provides examples of coding image data for profiles beyond Profile S. It corresponds with TIFF-FX (RFC 2301) Profiles F, J, C, L and M. This is provided for information only. The actual files used to generate the attached coding examples, together with the associated test cases an

41、d other TIFF-FX information, may be accessed at the following URL: http:/www.itu.intlITU-Tltiff-Mindex. html Recommendation T.37/Amd.l (09/99) 5 Content of TIFF-FX coding examples IV. 1 IV.1.1 IV. 1.2 IV. 1.3 IV.2 IV.3 IV.4 IV.4.1 IV.4.2 IV. 5 IV.5.1 IV.5.2 IV.5.3 6 Profile F . T.4 one-dimensional M

42、H compression, with 204 x 196 peld25.4 mm, big endian byte order, based on test file fD5x-02.tif and test case Profile F F5 T.4 two-dimensional MR compression, with 80 x 154 pels/cm, little endian byte order, photometric interpretation of black0 (Le. inverse image), cm resolution unit, based on test

43、 file fD6x-Ol.tif and test case Profile F F6 . T.6 two-dimensional MMR compression, with 400 peld25.4 mm, big endian byte order, multiple strips and no Global Parameters IFD (GP IFD), based on test file fD3x-02.tif and test case Profile F F3 . Profile J T.82 JBIG compression per T.85, with 300 peld2

44、5.4 mm, big endian byte order and no GP IFD, based on test filej01x-02.tifand test case Profile J J1 . Profile C T.81 JPEG compression with T.4 Annex E ITU L*a*b* color encoding, 4:l:l subsampling, 200 peld25.4 mm and little endian byte order, based on test file c03x-02.tif and test case Profile C C

45、3 Profile L T.82 JBIG compression with T.43 color encoding . One bit per component CMYK color representation, 400 peld25.4 mm and big endian byte order, based on test file 102x-02.tif and test case Profile L L2 Eight bits per component ITU L*a*b* palette color encoding, 200 peld25.4 mm and little en

46、dian byte order, based on test file 104x-02.tif and test case Profile L U. Note that the ColorMap tag (Le. tag code 320), present in this sample, is no longer used and may be ignored . Profile M T.44 MRC imaging structure for mixed texthe-art and color encoding Three layers with single strip per lay

47、er and little endian byte order: mask using T.6 two-dimensional MMR compression and 400 peld25.4 mm; background and foreground using JPEG compression with T.4 Annex E ITU L*a*b* color encoding; background at 100 peld25.4 mm and 1:l:l subsampling, foreground at 200 peld25.4 mm and 4:l:l subsampling;

48、based on test file m02x-04.tif and test case Profile M M2 . Three layers with multiple strips per layer and little endian byte order: mask using T.82 JBIG compression per T.85 constraints at 400 peld25.4 mm; background and foreground use X and Y Position offsets (Le. contains regions without coded d

49、ata); background using JPEG compression with T.4 Annex E ITU L*a*b* color encoding at 200 peld25.4 mm and 1:l:l subsampling; foreground using T.82 JBIG compression with T.43 lossless color encoding of ITU L*a*b*, DefaultImageColor (LayerBaseColor) other than black, and both 200 and 400 peld25.4 mm; based on test file ml lx-02.tif and test case Profile M M11 . Two layers with single strip per layer and little endian byte order: mask and foreground use X and Y Position offsets (Le. contains regions without coded data); mask using T.4 one-dimensional MH compression at 200 peld25.4 mm; foregrou