2.1.5 Internet Fax (fax)

NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 27-Mar-98

Chair(s):

James Rafferty <jrafferty@worldnet.att.net>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.Alvestrand@maxware.no>

Applications Area Advisor:

Harald Alvestrand <Harald.Alvestrand@maxware.no>

Mailing Lists:

General Discussion:ietf-fax@imc.org
To Subscribe: ietf-fax-request@imc.org
In Body: In Body: subscribe
Archive: http://www.imc.org/ietf-fax/

Description of Working Group:

Facsimile (fax) serves as a reliable, inexpensive global communications service. As the Internet becomes pervasive, integrating fax and Internet services is appealing in terms of cost savings and opportunities for functional enhancements. This working group will pursue a review and specification for enabling standardized messaging-based fax over the Internet. It will also develop informal requirements for faxInternet gateways as a first step toward devising standards for session-based fax over the Internet. The messaging-based (via e-mail) service will be specified first, since it should produce useful results for the least additional technical effort.

Facsimile/Internet integration can be considered in terms of two user service models, in order of increasing technical difficulty:

o Messaging (as with electronic mail) having high latency o Session-based, for observed delivery, with or without capabilities negotiation

Within these models, a real-time (telephone network replacement) based service is considered to be a subset of the session-based model.

For interconnecting fax services over the dial-up telephone network and carriage of facsimile message data over the Internet, two types of interface systems are required:

o Internet/Dial-up Fax gateway, moving data from the Internet to classic or Internet-aware dial-up fax products and services

o Dial-up/Internet Fax gateway, moving data from classic or Internet-aware dial-up fax products and services to the Internet

The dominant fax communications mode in use today is a session-based connection operating in real-timeover the dial up telephone network; hence an Internet-based direct replacement service would potentially save significant long- distance telephone charges. However, it is believed that from a technical standpoint this service is the most difficult task to produce over the Internet, whereas an messaging-based service is likely to be the simplest. In addition, it is anticipated that the two services will ultimately utilize at least some common technical components. Therefore, this working group will initially review and specify messaging-based fax over the Internet, using as much existing practice as possible.

The working group will take the following steps to specify a core fax-related messaging service over the Internet:

Terminology: Develop a shared set of terminology and definitions, to ensure a common framework for participants having differing backgrounds in Internet protocols and facsimile telecommunication.

Data Representations: Review existing facsimile- related Internet data specifications and accept, modify, replace or augment them, with particular attention to their encapsulation, such as via MIME.

Addressing and transport: Specify the mechanisms for addressing and receipt notification for facsimile data carried via Internet mail.

For session-oriented operation, the following specification will be created, as a basis for further work:

Operational constraints: Detail the operational constraints for achieving session-oriented use of messaging, tailored for timely delivery with the sender waiting for delivery confirmation. Existing protocols and data specifications will be used as much as possible.

The working group will take note of quality of service issues.

The working group will coordinate its activities with other facsimile- related standards bodies.

Goals and Milestones:

Jan 97

  

Submit Internet-Draft of data specifications

Jan 97

  

Submit Internet-Draft of terminology document

Feb 97

  

Submit Internet-Draft of messaging-related specification

Feb 97

  

Submit Internet-Draft of operational constraints document

Apr 97

  

Submit terminology document to IESG for publication

Apr 97

  

Submit data specifications to IESG for consideration as a standards track document

Jun 97

  

Submit messaging-related specification to IESG for consideration as a standards track document

Jun 97

  

Submit operational constraints document to IESG for publication as an Informational document

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2301

PS

File Format for Internet Fax

RFC2302

PS

Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration

RFC2303

PS

Minimal PSTN address format in Internet Mail

RFC2304

PS

Minimal FAX address format in Internet Mail

RFC2305

PS

A Simple Mode of Facsimile Using Internet Mail

RFC2306

  

Tag Image File Format (TIFF) - F Profile for Facsimile

Current Meeting Report

Minutes of the Internet Fax (fax) Working Group

Chair: James Rafferty

Reported by: Andy Mutz

I. ITU Cooperation

Rafferty reviewed the status of the cooperation with the ITU. T.37 (T.Ifax1) is up for approval in June 1998. It references the Service, TIFFPLUS, and Addressing RFCs. Rafferty is working with the Internet Society (ISOC) to submit the RFCs to the June meeting. ISOC is a member of ITU and can submit contributions.

T.37 has a "full mode" outline. An outline was produced with areas marked for further study. Intent is to have theses filled out for June 1998. Goal is to produce single set of standards shared by IETF/ITU. The focus of "Full Mode: is on capabilities exchange and confirmation of receipt. There was interest by ITU members at the January meeting in using IETF WG documents for full mode. There is also some relevant work taking place in the conneg wg.

Proposal: Submit IETF WG documents on extended mode for the June SG8 meeting as ISOC contributions.

The room supported the plan to contribute the IETF WG documents to the ITU June SG8 meeting.

II. Charter Review

Original Charter is more or less completed. Should additional work be done?

Draft charter was sent to ietf-fax mailing list last week.

Key Milestones:

ITU is also likely to have a fall interim meeting, and RFC's from IETF will be discussed there.

Comment: Charter doesn't have to constrain organization of documents. JR: ITU may want Session-mode broken out because it competes with ITU work. Session mode work is less mature at this point.

What does move to draft standard status demand? At least six months and two independent implementations which interwork. Rafferty indicated that implementors in the group should plan to work on this during the next six months.

Conclusion: A straw poll was conducted on the draft charter. Consensus for the updated charter was noted. The chair will accept comments on the charter until the following Wednesday and then submit to the area directorate.

III. Goals and Terminology

The current document draft-ietf-fax-goals-02.txt was presented by author Larry Masinter.

Masinter summarized the history of the document and noted that it was originally written as a requirements document, but then was rewritten as a guideline for what is to be specified.

Masinter pointed out some additional corrections that are needed:

Substantive issues with -goals-.

Editorial issues

The Introduction defines levels 1,2,3 as a means of stating the importance and viability of guidelines in the draft. Masinter characterized the levels as follows:

1. Everyone wants it.
2. Some people want it strongly.
3. Everyone thought it was a nice idea, but not crucial.

Rafferty requested that the work group review the document and check the "levels" for the items in the draft to see if they properly reflect the wg sentiments.

Masinter went on to review the content of the draft.

Questions or issues on the document:

With regard to user experience: immediate delivery, confirmation. Suggestion: fax has positive delivery confirmation while email has negative delivery confirmation.

Comment: Document might want to discuss elements of email in more detail. Response: Document is intended to NOT rely on email, and be independent of it. Any solution has to integrate with network at transport layer and work appropriately with application layer components.

Suggestion: Section on using existing facilities could include a note on registering additional fax status codes, etc.

Security section: It was noted that this section is less extensive than that provided in Service. For example, nothing about authentication was noted. Should it be added to address legal requirements? This was generally accepted, but it can be noted that the service document has a more complete description of security requirements.

There is some inconsistency in the 1/2/3 levels related to working with email. Email in one section is a 1, and later is not 1. This will be reviewed. General consensus is that interworking with email IS a requirement. Session mode interoperability with email is under debate. Context is important; store-and-forward fax must be based on email. Other kinds of fax may be compatible with email, but might not have to be.

What are we envisioning as the scope of effort for internet fax? To deal with this, the intention of this document is to set the proper 'floor' in terms of requirements. On this issue of whether this aligns with simple mode, it was stated that the document is not related specifically to simple mode.

Masinter suggested that everything ranked 1 in this document is a requirement for full mode. 2's are viewed by SOME as a requirement for full mode. 3's are viewed as desirable for full mode, but may not be feasible for various reasons. .

Comment: There is some ongoing debate over how to label sets of features; Masinter feels this debate should be taken out of critical path. In other words, the precision required to resolve feature issues in more detail should not be pursued in this document at this time, since this will be addressed in the protocol documents. .

Conclusion: It was suggested by the chair (and agreed by the author) that comments on the current draft should be submitted by next Wednesday and then the document will be updated. The plan will be to then submit the document for working group Last Call. Those present supported this plan.

Extended/Full mode discussion

IV. Presentation of Current Drafts

Related Drafts

Larry Masinter presented the Eifax draft.

Eifax is the simplest possible set of old 'fpim' draft work. The document previously called FPIM has been split into 2 documents: a small document which addresses protocol issues for extended (full) mode operations (eifax) and a larger document with primarily informative material, such as information about Gateway behavior, which has been renamed as Operational Constraints.

Per Masinter, the Eifax document requires editorial work and security section. There are proposals for handling Delivery Confirmation and Capability Exchange in this document. (The discussion on these topics took place later in the meeting.)

Comment: More information on Location and change-control of feature registry should be added to eifax.
It was suggested that a single feature registry subspace can be established for ITU, for example. Feature values can be referenced to an ITU document as well, for example (such as t.30)

Draft-ietf-fax-mdn-fullmode-01

Toru Maeda presented this draft.

Maeda stated that Fax device manufacturers have agreed simple mode alone is not enough to meet all of their requirements. Full mode is intended to include capability exchange and confirmation. He also indicated that end-to-end use without changing email infrastructure is a requirement.

The draft describes phases for a capability exchange process. A capability request can be made by requesting a special MDN and then the capability response is returned in a special MDN. This draft uses a T.30 frame as the way to state capabilities of the recipient Ifax device. It was stated that the T.30 frame is desired for representing capabilities because of the needs for Gateways to/from G3Fax.

There were some questions and comments made.

Comment: What capabilities problem is being solved here?

1) ON-ramp to Off-ramp with gateways, a session-based real-time activity, or 2) pure store-and-forward

Answer: Primary problem being solved is session-based. Three main components of capabilities are involved: mechanisms for exchange, features being negotiated over, and syntax. The focus is on communication over the Internet with concern over gateways.

Comment: Two levels of capability might be used: 1) document capabilities, and 2) transmission aspects like modulation that may only apply in certain cases. Both may be necessary in some gateway environments. This implies that different levels of capability exchange may be needed for the two different environments.

Maeda stated that the preference for fax manufacturers is to use T30 frames for all of these needs, but other manufacturers either were not present or did not state opinions. .

The chair noted a key point: there is a need to examine appropriate extensions to MDN and DSN needed for operating in this environment and the concepts in this draft can be input into this.

V. Capabilities Exchange Discussion

Rafferty reviewed the results of the Capabilities Exchange informal meeting held earlier this week in an overhead slide. He noted that capabilities exchange needs to address three somewhat independent issues: mechanisms, features and representation (or syntax).

The interim meeting identified several possible mechanisms: send MDN, request method, ESMTP new keyword, directory based capabilities.

A need for scenarios was identified. A preliminary draft on this topic was written after the meeting by Graham Klyne and posted to the list. Comment on Features: The chair felt that is a need to go through the DIS bits and frames, and identify elements to be taken account of and note those elements which are really irrelevant for capabilities exchange.

Comment: Things like "media" have been defined in printer MIB and media definitions already in use should be used and not re-invented.

The chair stated that there is some overlap between the fax needs for capabilities exchange and the general needs for capability exchange for Internet applications that are now the focus of the conneg working group. Ted Hardie, the chair of the conneg work group, was invited to summarize the direction of the conneg work.

Hardie review the current drafts and their purposes for potential fax use:

Draft-ietf-conneg-feature-reg-00.txt

Draft-ietf-conneg-media-features-00.txt

Draft-ietf-conneg-requirements-00.txt

Draft-ietf-conneg-feature-algebra-00.txt

Capability Exchange Mechanisms

Related Drafts:

Methods:

Dan Wing presented the MDN features draft, which specifies that capabilities can be added to an MDN as already used.

Wing had previously wrote another draft (draft-ietf-fax-smtp-capabilities-00.txt) on the potential use of a capabilities key word. Using this approach, during connection to SMTP server, one can request capabilities of the connected device or users preferences.

Comment: There are hairy issues around caching MDNs that become stale. One work-around is to send messages which include both simple-mode file format, as well as sending an enhanced file format, using the MIME multipart/alternative structure. It was noted that this may be impractical for Inet fax terminals, since the terminal may run out of memory if attempting to send two messages (simple and enhanced) at the same time.

In store-and-forward environments, there are problems with current capabilities and cached or perceived capabilities of recipients. The group felt that different capability exchange mechanisms should be examined and the most appropriate one or ones should be recommended. Interworking remains a big concern.

Question: Problem with approach of sending a blank message to get an MDN back with regard to privacy.
Answer: D Wings proposal does not propose sending blank messages.

Comment: Multipart alternative can be used, but it may be impracticaly slow.

Comment: Out-of-band information can always be used, just as now any kind of document can be sent by email if the sender desires. This protocol discussion is intended to reduce reliance on out-of-band communications.

Comment: There is a lot of flexibility in various approaches including sending a list of URLs for each type of enhanced document. This is basically changing the paradigm away from sending everything first.

VI. Capability Exchange - Features

The following items were within the scope of this discussion:

Media features:

T.30 frame contents

Type of service (e.g., polling) versus. Doc characteristics

Capability Exchange Expression

Feature expression - syntax

Simple and complex cases

Potential use of conneg work.

Discussion of Features

Comment:

There are two positions being expressed in drafts regarding feature expression. - t30 frames versus. other methods, such as the conneg media features list. What makes t30 frames a requirement? Part is culture, comfort level and the many existing implementations. The focus there is on G3 fax and the Mechanism is considered safe.

If the intent of Inet fax was strictly for communication between G3 devices, then this would be a good model. However, if the intent is to interact and integrate with the larger internet community, then some information loss is possible but going beyond T.30 will be necessary.

Opinion: To grow the fax market beyond legacy G3, Inet fax must go beyond t30. A tradeoff is between loss of t30 details vs. loss of market/community/capability.

This work group has been focused on integration, particularly since the ITU is already pursuing a T.30 centered approach in its real time Internet fax work. The market will decide which way to proceed.

Further discussion was deferred until the next day as time ran out. A continuation of the discussion on Extended/full-mode was on the agenda for the second day. .

On April 2, the following agenda was proposed, with the chair agreeing with a suggestion to allocate time to continue the capability exchange discussion as part of the extended/full mode wrap-up.

Agenda:

Confirmation of receipt 45 min
Extended/full mode wrap-up 30 min

Session mode 20 min

Operational constraints with gateways 30 min

Wrap-up

Confirmation of receipt

This is a key facsimile feature that has been widely identified as a user-perceived need for an Internet facsimile standard.

Reference documents:

draft-ietffax-eifax-00.txt, RFC2298 (MDN), draft-ietf-fax-dsn-extensions.txt

The chair reviewed the work of informal meeting earlier in the week. The conclusion of that group was that Both MDN and DSN are needed. There is a need to review scenarios and write up implementation guidelines. Limitation of DSN is requirement of participating MTAs. One can determine where the DSN transmission 'stopped'. SOME indication of message receipt will occur.

MDN can go (in theory) beyond DSN, and add notion of whether document is seen or processed by a user agent. MDN has notion of status codes that may be applicable and/or extensible for Ifax. There are different possible levels of confirmation, for example if a gateway receives confirmation from a g3 device confirming successful receipt.

Graham Klyne: Message confirmation issues in internet fax.

Draft-ietf-fax-confirmation-scenarios-00.txt, posted to list but not yet published as a draft today.

The scenarios draft discuss differences between email and G3fax:

Current message confirmation mechanisms

Confirmation options and scenarios

Question: what about error conditions?
Answer: This is an appropriate topic, but it hasn't been discussed in the draft yet.

Question: Why does the draft describe real-time fax image transfer?
Answer: Trying to open debate to non-email delivery, from the perspective of interaction with ifax.

Question: security considerations.
Answer: Security issues informing discussion are highlighted. Mostly concerned with privacy. MDNs with user-operated terminal can give information about user. There are other issues as well; this is a starting point.

Suggestion: Add issues of multiple copies and redistribution to security concern.

VII. Review of Informal Meeting:

Conclusion: Both MDN and DSN needed

The chair checked the room with a straw poll on this conclusion, but there was not quite a consensus on whether both are required. A preference was expressed by some for having only one method.

The discussion continued, as an attempt was made to fine-tune the requirements. Some of the points raised in the discussion follow.

MDN is disposition beyond delivery to a final agent; printing, forwarding to G3 device, display. Discussion was held over MDN versus fax model. Normally there is not automatic return of MDN; it is a manual act. For fax, a special version of MDN generated, perhaps automatically, is under discussion. There are security issues around this.

There is a difference in time between delivery to MTA and download (for example) via POP by user. DSN provides confirmation of delivery to MTA. MDN provides notification of delivery to user's display agent.

Comment: The more fax-specific work gets done, the less the two worlds of email and fax are united. Internet mail has a useful style of service that is less stringent than fax. Preferred idea is to raise the level of email performance to email level. Fax has the concept of delivery confirmation, but not the concept of read-receipt (just g3 machine receipt.) DSN does not actually mean the message got to the last MTA but to the mailbox. POP or IMAP download is more appropriate for MDN notification than the 'read' act. It's probably acceptable to develop automatic notification for message download using MDN (and not automatic notification for 'read'.) (D Crocker)

ANS: MDN's have been designed for extensibility. Selecting an appropriate message is the idea.

Comment: Fax-specific code should be avoided (and the notification should be 'universalized' to include email.)

J Rafferty: Comments from mail community are solicited.

L Masinter identified four different scenarios to be considered:

1) A person in front of a PC using POPmail connected to a message store.
2) An automated machine like a fax machine, periodically connected via POP.
3) A permanently connected 'offramp'.
4) An SMTP server permanently connected.

If only DSN's are used, the autofax machine won't give real notification unless MDN's are auto-generated. The user at a PC receiving email will have the option to send MDN or not send MDN. Needs DSN. Offramp could use either but MDN is more complete. The SMTP server could use either one.

Comment from Greg Vaudreuil: In the case of a busy signal such that we will known error conditions. That work exists for DSN, but not MDN. Some error conditions might need clarification for the offramp case in the MDN framework

Comment: Why don't MDN's suffice for all cases?

Comment: Problem with 'need DSN': trying to improve stochastic situation but not fixing problem. Scaling behavior is poor if both DSN and MDN are always used; two notifications for every message. A major feature for permanent use is being built to deal with a transient. In the long term, only ONE should be specified as a permanent solution.

Comment: Are these positive or negative notifications or both? If you include negative notifications,
Does the diagram change? For the negative case, DSN is needed in all cases. From a VPIM standpoint, DSNs were used for this reason. In VPIM, MDNs are optional additional features.

The Eifax document specifies: the sender decides whether to ask for MDN or not. For EIFAX machines, MDNs must be returned if asked for.

Full mode has been specified to require positive AND negative confirmation, and there is consensus on this point. The question is on how to accomplish this with only one mechanism?

Comment: MDN is being suggested to support a new behavior; the document is now under the 'user's control.' Perhaps this can be done by changing DSN behavior. Right now, DSNs are generated before 'real delivery' on POPmail. Actually it SHOULD be generated on FINAL delivery. This would benefit entire community (Crocker.) DSN should reflect 'real delivery'. The cases for connected and disconnected users are fundamentally different.

Harald Alvestrand: In the real world, people have been using this system (DSN) and use it to confirm the machine connection. Changing this existing model to reflect the above position would disrupt today's system.

Crocker: We need a functional end-to-end mechanism. DSN is right in terms of meaning, but not right in terms of common practice today. Question: If the mail wasn't delivered by email for a month, isn't that important?

Rafferty: The reality of fax is that you never know what's on the other end. SOME information about delivery is much better than nothing for end users. It is good to know that the message reached an intermediate point. The more immediate the feedback, the better. The more complete the information the better. DSN is immediate. MDN might take longer, but is complete.

Vivian: You don't want email to inherit shortcomings of fax regarding notification.

Graham: A way of interpreting DSN confirmation consistent with current fax use is possible: Some action on part of recipient is required to view message. (e.g., Pick up piece of paper, connect to POP server.)

Comment: MDN's have real privacy concerns, and DSN's have less concerns. Extending DSN's could introduce new security concerns.

Conclusions:

The discussion was concluded with straw polls to check the room for consensus on key points.

Straw poll: In order to satisfy positive and negative confirmation as fax has today, there was a mix between people who think DSN and MDN both required, and people who think DSN alone suffices (inconclusive)

Vivian Cancio suggested that the primary value of MDN will be to provide a "value added" receipt capability that goes beyond what G3 fax has done.

A straw poll was conducted to see if the room is in favor of using MDN to provide service beyond current functionality as value added. There was a consensus supporting this concept among those present.

Second Straw Poll: If MDNs are used for value-added function only, how many people would be satisfied y DSN used only as a means for notification. There was a rough consensus favoring this approach. These conclusions will be checked on the list.

Comment: Further discussion on list is needed to instruct the editor on changing current draft to reflect these consensus points. .

Extended/Full Mode wrap-up.

Addressing: Claudio Allochio
.
There is a need to finalize extended addressing capabilities. The work is of interest to VPIM, telephony, etc. There is a draft currently requiring updating which describes extensions which can be done in addressing. Global dialing, extension dialing, password dialing, and recipient name need to be specified. For interoperability, addressing needs to be shared. The minimal case has already published as RFCs. Claudio intends to post an Extended options document to the list.

Concerns that IP telephony space has independent groups doing overlapping work in this area. Extensions are applicable well beyond fax, but consensus with other groups must be reached.

Question: Will there be registration for extensions like service selections?
Answer: Choice is for registration or for new RFCs. No decision made. Suggestion: registration is more open.

Comment: This work (extensions) will be controversial. It will probably take months to specify and get buy-in from the affected communities.

Capability Exchange mechanisms

Draft-ietf-fax-mdn-features-01.txt
Draft-ietf-fax-mdn-fullmode-01.txt

The discussion on this topic was picked up where it left off from the day before.

There was a review of mechanisms, to see which ones the group feels are best to support.

Mechanisms: MDN mechanism: An MDN extension would provide list of capability of recipient.

Second proposal: A keyword would be implemented in ESMTP to request capabilities return. This has advantage of immediacy.

Third mechanism: A directory lookup populated by some means. Capabilities or device or application

Fourth mechanism: T.30 protocol over live PSTN to get capabilities. (Out-of-band)

Fifth mechanism: Capabilities sent with message so the recipient has a current indication of how to respond (cached.)

Sixth mechanism: Generic out-of-band transmission.

Comment: Strong negative feelings were expressed about MDN and ESMTP regarding privacy and security and the use to build junk-mail targeting list. Both provide simple attack means. Directory lookup is much simpler to protect. Cap with message does not have same security problem.

Harald Alvestrand: Capabilities with the message only works when messages are flowing in both directions.

Richard Shockey: echo security concerns. Suggests a cap exchange mechanism in the event of failure. Polling for capabilities is bad.

Comment: IPP supports capability requests using salutation, LDAP, and request.

Comment: Capabilities can change with some frequency. This can be a drawback in directory case.

Comment: Short lifetimes are not a huge problem for directory services.

Question: How to repopulate directory with short lifetime of capability? Mechanism to populate directory required. Many mechanisms are possible.

Comment: These concerns about MDN and ESMTP don't line up well with previous discussions on list.

Question: How to populate directory?
Answer: Add automatically in capable environments. Sending cap with messages is popular.

Comment: All this work is targeted at going beyond manual configuration.

Key exchange as example: It might be manually initiated, but it's not manually entered.
Directories are used, but not widely now.

Larry:

MDNs were originally suggested because the security concerns about adding additional information have already been addressed for confirmation. Vcard doesn't satisfy requirement for capabilities in 1-way communications. Other mechanisms had been in FPIM draft. In fax it's traditional to settle on a single 'base' method.

Comment: There is a security issue: the possibility that the machine issuing MDN can use a directory to determine whether or not to return MDN. The addition of a security section to the draft will clarify matters. Possibly, the result would be that the combination of MDN and related directory lookups would as strong a mechanism as using directory itself.

A straw poll was conducted to see if there was a predominant primary mechanism.

Poll: What should be the primary mechanism for capability exchange?

Result: MDN is supported by a rough consensus of the room as the primary choice: three opposed and a bunch supporting and a lot abstaining.

There was some support for ESMTP Cap keyword as a secondary mechanism.

Directory lookup as primary approach? NO.

PSTN as primary: No.

Capabilities with message as primary means for cap exchange? No

Combination of directory lookup and cap with message. Some support. 5-10 people

MDN with directory lookup as secondary. Much support.

Conclusion: There is no clear consensus right now, but it is leaning toward MDN combined with dir lookup.

The chair suggested that the result supports continued study of MDN for this purpose and the expectation that this may be used in conjunction with directory lookup. Implementation is in early stages for both MDN and LDAP.

Final comments: conneg work should be compatible with both MDN and LDAP.

A single semantic is required. Suggest VCARD and URL-based. (??)

Feature exchange:

Cap exchange features - point made that conneg is focusing on media features independent on facility. TIFF profiles and document characteristics.

Requirements include hard-copy target device support and applications that may be more flexible in terms of information they can accept.

There is a need for dealing with internet fax and not just a t30 terminal. For example, T.30 does not deal with tiff profiles and internet fax does. There has been discussion suggesting using T.30 frame content. Large portions of t30 frame content do not really apply as media features in the context of conneg such as bft, polling, mode of service. It's been suggested that a large bitmap of t30 features also does not fit well within conneg. Ted Hardie confirmed that a mapping of t30 features to media features would be quite possible and more general than a direct use of t30 bits.

The chair stated that T.30 frames do characterize behavior of fax machines. He proposed that a subset of these bits should be mapped into the conneg scenario.

Graham Klyne requested comments on his work on conneg and its relation to fax.

Larry Masinter presented the conneg media features draft. The intent is to use these elementary features to build a media description to describe a device as a boolean expression.

The chair reiterated the need to do a completeness analysis on t30 and conneg for overlap. Masinter stated his belief that the media information in t30 is captured by the tags in media features.

It was noted that the TIFF profiles may sometimes be looked at as a subset.

Maeda restated his position that the T30 frame DIS bit is very well understood. Using it as expression of capability is useful. For case of gateway to g3 fax machine, t30 frame is highly useful.

The chair noted that T.30 frames alone don't handle all cases, particularly for the use of TIFF within Internet fax. The issue being studied is how to express the features held within the T.30 frames and make sure they are complete within the context of Inet fax capabilities exchange. This concluded the discussion as time ran out.

VIII. Operation Constraints

Dan Wing made a short presentation of the constraints document (draft-ietf-fax-operation-00.txt).
Topic addressed in the document include what should be on cover pages, a discussion of why MDNs should not be implemented automatically, etc. The draft includes material extracted from FPIM and some new material. Further discussion on this draft is encouraged and deferred to the list.

This concluded the meeting.

Slides

IETF Internet FAX - Agenda
Extended MDN for IFAX Full Mode

Attendees List

go to list