Subject: draft-ietf-fax-t30-capabilities-00.txt

From: Graham Klyne <[email-masked]>
Date: Wed, 09 Sep 1998 18:47:11 +0100

Dan,

Again, my apologies for the delayed positing of my comments.  Some of these
might be superseded by ongoing work to analyze the T.30 DIS/DTC bits and
build a decision table for mapping them.  I think this memo may be an
appropriate document to contain such a decision table.

In addition to the comments below, I note that Maeda-san's draft also
contains mention of SUB, SEP, PWD, SID and other T.30 values that we may
need to consider.

#g

[...]
>1.  Abstract
>
>   This document describes how the DIS Standard Capabilities and
>   Non-Standard Capabilities (NSF) of [T.30] can be expressed using the
>   format described by the IETF Content Negotiation Working Group
>   [MEDIA-FEATURES, FEATURE-ALGEBRA, FEATURE-REG].
>   
>   The format described in this document, and the format described
>   in [FEATURE-ALGEBRA] is intended to be usable in many Internet
>   protocols and by a variety of methods.  The specific methods
>   are not described by this document.

I note that many T.30 capabilities map directly to media feature tags.  But
there are dependencies in T.30 that need to be captured, and in some cases
must be mapped to more complex feature tag combinations.

>2. Introduction
>
>   To exchange documents between a sender and recipient it is important
.......<------>...........<----->..........<->
        send               from             to a

>   to know the display or print capabilities of the recipient.
>   
>   The fax protocol [T.30] has a long-established method of 
>   exchanging capabilities.  The fax protocol requires a realtime
....<--------> "identifying"

>   connection between the sender and receiver, and is not designed
>   to be cached by the sender or to be shared with multiple senders.
>   Additionally, the [T.30] capabilities exchange describes many
.............................................................<--> (delete)

>   data link layer specific information which is not applicable
......................................................<--------> relevant?

>   to an Internet application layer program.

[...]
>   Non-fax devices and software which creates, manipulates, or prints
>   images are more likely to use capability expressions which are more
>   portable across multiple devices than the capability expressions of
>   [T.30].

I felt this paragraph was redundant in view of other content of this memo.
   
>   The portion of the T.30 protocol used to indicate the
>   capabilities of the recipient is the DIS Standard Capabilities
>   (section 5.3.6.2.1 of [T.30]) and the Non-Standard Capabilities
>   (NSF, section 5.3.6.2.7 of [T.30]) which is used for vendor-
>   specific extensions.

Reference also Table 2/T.30 (I think).

I would suggest some additional text here, along the lines of:

"This memo sets out representations for the capabilities expressed in T.30
that are more appropriate for use by message sending Internet protocols,
which in general do not relate to fax transmission."

[...]
>3. Mapping DIS
...........<--->  T.30 DIS bits

>
>   The following DIS bits and their function are described in [T.30] and
>   mapped using the descriptions in the following sections.  The
>   following sections use ABNF [RFC2234] to describe the syntax.
>
>     DIS bit number     T.30 use                          Section 
>     --------------     --------                          -------
>           1            Reserved                          
>           2            Reserved 
>           3            Reserved 
>           4            Reserved 
>           5            Reserved 
>           6            V.8 capabilities                  3.1
>           7            256/64 octets preferred           3.1
>           8            Reserved
>           9            Polling                           3.2
.........................<----->
(more specifically: polling for image data, I think)

>          10            Receiver fax operation            3.1
>         11-14          Data signalling rate              3.1
>          15            Paper size                        3.3
>          16            2D coding capability              3.1
>         17-18          Scan line width                   3.3
>         19-20          Page height                       3.3
>         21-23          Scan line receive rate            3.1
>          24            Extend field                      3.1
>          25            Reserved                          
>          26            Uncompressed mode                 3.11
>          27            Error correction mode             3.1
>          28            Must be 0                         3.1
>          29            Reserved                          
>          30            Reserved                          
>          31            T.6 coding                        3.4
>          32            Extend field                      3.1 
>         33-39          Reserved                          
>          40            Extend field                      3.1 
>          41            Paper size                        3.3
>          42            ?                                ?
>          43            Paper size (inch/metric)          3.3
>          44            Inch resolution preferred         3.5
>          45            Metric resolution preferred       3.5
>          46            Scan line receive rate            3.1
>          47            Selective polling                 3.2
>          48            Extend field                      3.1
>          49            Subaddress                        3.6
>          50            Password                          3.10
>          51            Ready to xmit (polling)           3.2
.......................................<------->
(more specifically: polling for binary data, I think)

[...]
>3.1.  Not Applicable to Content Negotiation
.........................<-----------------> "Media Feature Description"?

>3.2.  Polling 
>
>   With SMTP polling is acheived with the TURN, ETRN, and
>   ATRN commands [ref].
>   
>   With HTTP polling is acheived with GET [ref].
>   
>   With FTP polling is acheived with RETR.
>
>   Thus, information about a remote machine's ability to have messages
>   polled is not useful to use over the Internet.

I understand that the T.30 bits are also used to indicate that there is
data ready to be sent by the polling mechanism (i.e. more than just
indicating a polling capability).

>3.3.  Paper Size
>
>   Paper size is expressed as:
>   
>     papersize = "Papersize" "=" token
>     
>     token = "na-letter" / "iso-a4" / "iso-b4" / "iso-a3" / "na-legal"

I suggest also referencing /'ix-x' and 'pix-y' in Larry's document.

>3.4.  Group 4 Facsimile
>
>   ?  What do we want to say about group 4

I don't see any relevance here to media features for Internet protocols.

>3.5.  Inch versus Metric resolution
>
>   The algebra of [FEATURE-ALG] handles both metric- and inch-
>   based measurements.

This is no longer true.  Each feature uses a specific unit (which for
resolution is currently dpi, and for paper size is token-based.  Thus, we
shall have to translate the T.30 units into standard media feature units.

[...]  
>3.7.  Binary File Transfer
>
>   Binary File Transfer is acheived on the Internet using FTP,
>   HTTP, and MIME messages in SMTP.   

I effect, *all* Internet messages are binary, with TIFFbeing used to
represent fax image data.

>3.8.  Color Transmission
>
>   ?  What do we want to say about color

I hope and expect that we shall be able to find ways of carrying fax colour
data within the media feature framework.
   
>3.9.  JPEG Encoding
>
>   For Internet Fax we are only supporting TIFF->FAX and FAX->TIFF.

TIFF-FX incorporates JPEG coding (among others) as an option, so we should
be able to represent this as part of media features.  Currently, it's
lumped into the TIFF profile, but I would not be surprised to see some of
this separated out.

>3.10.  Password
>
>   The password, used to authenticate the recipient, is
>   equivalent to the password necessary to retreive POP (or
>   IMAP) messages from a POP (or IMAP) server.  Similar 
>   authentication is available with SMTP with [AUTH], and
>   with the password with FTP.  
>   
>   With SMTP, stronger authentication is available with [SMIME] or
>   [PGP-MIME] and [SMTP-TLS], and with HTTP with [HTTP-SSL].
>
>   The fax offramp may wish to use the legacy machine's supplied
>   password to authenticate the recipient.  This could be done
>   by comparing a special field in the recipient's email address
>   (if using SMTP), such as "/T30PASSWORD=8924".

My my mind, this relates to T.30-based fax security only, and is simply not
applicable to e-mail based security.  I base this view on the principle
that "security cannot be gatewayed".

Therefoe, I think this is not relevant to Ifax.

>3.11.  Compression
>
>   XXX - we need to determine if the offramp will be responsible 
>   for changing compressions, or if this will be something that
>   is expressed as one of the CONNEG features.

Are we talking about T.30/TIFF-FX compression techniques here?  (i.e. MH,
MR, MMR as defined by ITU T.4, T.6)  Or is this a broader issue (e.g. GZIP,
etc.)  If the former, I see this as similar to JPEG encoding (see above).
If the latter then I think we may need to look to use of different MIME
types;  currently, to me, this seems well out of scope.

>4.  Mapping Non-Standard Features (NSF)
>
>   Many fax manufacturers support features that are not part
>   of the [T.30] specification.  These features allow better
>   compression, higher resolution, or provide other similar value-
>   add features.
>   
>   Each fax manufacturer which wishes to provide such a feature
>   should map the feature to the algebra described in [FEATURE-ALG].
.......................................................<----------->
I think this may be the wrong citation.  I think that something like "...
map the feature to one registered with IANA per [FEATURE-REG]." would be
closer.

>   This allows the feature to be expressed to senders using
>   the same mechanism as described in section 3 of this document.

Absolutely!

------------
Graham Klyne
([email-masked])