Subject: Call for Discussion on Response to Communication 2 from ITU

From: James Rafferty <[email-masked]>
Date: Fri, 03 Sep 1999 13:22:32 -0400

Folks,   

The ITU sent the WG a communication on the matter of synchronization between
the 
ITU fax work and the IETF work.    We need to respond to this in time for 
the response to be considered at the upcoming Question 4 rapporteur meeting
which is planned for Sept 20-23.   

The text of the communication was as follows:   

>ITU-T Study Group 8, Question 4, wishes to utilize the efforts of the
>ISOC/IETF Fax working group, to facilitate on-going synchronization of
>the facsimile-over-email work being developed by ITU-T and ISOC/IETF.
>Terminal Characteristics
>
>
>The ISOC/IETF Fax working group is responsible for developing technology
>that permits emulation of facsimile service, through the existing
>Internet email infrastructure.  The quality of a hybrid service, which
>utilizes components from the ITU-T T.30 GSTN-based facsimile service and
>the Internet email facsimile emulation service, is facilitated by close
>synchronization of the technical details between the two services.
>
>
>The ITU-T T.30 service is regularly enhanced to permit new terminal
>characteristics, such as additional resolutions and two-sided printing.
>Incorporation of such characteristics into the current ISOC/IETF
>facsimile-over-email specifications appears to require the full
>involvement of a newly chartered, developed, reviewed and approved
>ISOC/IETF standards effort.  An effort of this type can take as much as
>one year.
>
>
>Question 4/8 requests that the ISOC/IETF working group on facsimile
>explore creation of procedures which permit incorporation of new
>terminal characteristics more quickly.  It appears that this would
>require changes to RFC 2301, for file format, and RFC 2531, for
>facsimile capabilities format. One possibility is to create procedures
>for addition of extra-standards registration of new characteristics,
>through the Internet Assigned Numbers Authority.

We had some discussion on this at Oslo.  The relevant sections from the
minutes are below, and then I will add some comments.   

>+ Communication 2 on Synchronization:
>It is stated that there is a need for synchronization between ITU T-series
>fax recommendations and IETF RFCs, especially where 
>they cross-reference each other. When new T.30 features are added, how are 
>updates to TIFF and fax feature schema handled?
>
>
>The chair presented 4 cases and their potential handling.  
>[[see James' slides for more details]] 
>
>
>1)  Revision to T.30 -> New fax feature tags
>Discuss:  Needs IETF review  to incorporate (per Conneg rules) (?)
If T.30 is changed in a way that needs new fax feature tags, this 
is a fairly major change.  An example that is coming up is the pending
change to add support for "double sided printing" to T.30 (targeted for
approval
in February 2000).   It would seem the approach to follow here is driven by
the

Conneg registration procedure and related rules for establishing new tags 
per RFC 2506.   

If new tags are to be registered in the IETF tree, the rules per RFC 2506
are: 

"The IETF tree is intended for media feature tags of general interest
   to the Internet Community, and proposals for these tags must meet the
   "IETF Consensus" policies described in [5].

   Registration in the IETF tree requires approval by the IESG and
   publication of the feature tag specification as an RFC.  Submissions
   for feature tag registration in the IETF tree can originate in any WG
   of the IETF or as an individual submission to the IESG."   

This implies that the new tags would need to be defined in an RFC as
well as registered with IANA, assuming that it is logical for the 
tags to be part of the IETF media features "tree".  

To the extent the Fax WG or a successor fax oriented WG is in place, 
these kind of changes could be done within this WG, with consultation with 
the ITU as well.   It would be useful as well to have consultation with 
Conneg experts within IETF (which may or may not be in an active WG). 
 
If there is not an active IETF fax WG, the next best thing would be
to at least have a related mailing list of people who continue to 
be interested in IETF issues related to fax.  Related Internet drafts as
individual submissions could be produced and reviewed on such a list; 
it would also be possible to have IETF BOFs for a small set of issues.   

Clearly, this whole topic brings up the issue of how the communication 
and cooperation related to fax will proceed going forward, especially 
if the Fax WG concludes or is suspended; I suggest we take up this
more general topic later on as a separate bullet item.  

An alternative approach would be to add new tags which were not
in the IETF tree, especially if the ITU wanted to drive this activity. 
It looks like these kind of items could be put as ITU entries in the 
"Global" tree.   

Per RFC 2506, the review requirement here is:  

"Registrations of feature tags in the global tree must meet the
   "Expert Review" policies described in [5].  In this case, a
   designated area expert will review the proposed tag, consulting with
   the members of a related mailing list. " 

If there was not a currently active Fax WG, this might be the most practical
approach.  However, consultation with IETF people that had Fax and 
Conneg experience is still highly advisable and consistent with the apparent
intent of
RFC 2506 .   Even in this instance, 
there would be a practical need to have a document which provided
the specification for the new tags, as backup to the registration.   

Can I have comments on whether people have a strong preference
between keeping this in the IETF tree, vs. opening it up to be
dealt with in the global tree?   

>2)  New values for existing fax feature tags (based on approved amendments
>to T.30)
>Discuss:  More streamlined  process  may be possible to update valid values
>and IANA registry
This is a simpler case.   We already have a situation which fits this model.  
Last April, new resolutions were approved for Black and White fax documents
within Group 3.  So, we could use this as a test case on how to handle 
such matters.   

The alternatives would seem to be:  

 1.  Update the fax feature schema doc (RFC 2531) to include the new
resolutions; 
if there were other reasons as well to amend the document, it could be
recycled

as proposed.  
2.  Do a fax feature schema extensions draft which updates RFC 2531 and 
updates the IANA registrations to add new legal values; then later
combine both into a consolidated draft std.   

If a Fax WG and / or conneg WG was not available to review such extensions, 
an IANA registration could be prepared to propose extensions in values and
this would presumably require review from a designated IETF expert (s).   

Comments? 

>3)  Revision to T.30 attributes which may affect TIFF (RFC 2301) profiles
>Discuss :  appears to need IETF technical review
>
There are 2 cases here, which are analogous to the situation for 
feature tags.  

a.   Use existing fields, but add to the list of legal values

This is the simpler case where only the permittted values for an existing
field
would need to change, but there are no TIFF structural changes or
needs for new TIFF fields.   

However, to date, the method for making such changes would
appear to entail the production of an RFC by either a WG or via the IETF
consensus
process.   

There is currently no IANA registration for TIFF at any level below the 
"image/tiff" MIME media type.  To my knowledge, Adobe is still
the TIFF custodian which would review new fields and sign off
on the new tag numbers to avoid duplicate assignments.   

It sounds to me like there are several obstacles to creating
an IANA registration tree for TIFF fields (Adobe as the current
custodian, no current TIFF field registration, etc.)  

This leaves us with the creation of RFCs in IETF or with 
normative documents by the ITU which essentially extend
RFC 2301 as the approach for adding support for new values.  

What do people think?   

Case b.  

A change to T.30 creates the need for new TIFF fields or
has major TIFF structural implications that go well beyond RFC 2301.  

This is similar to the case where there is a need to create new feature
tags.  
An example case here is the pending addition of JBIG-2 compression 
support to T.30 using new MRC profiles, none of which have yet 
been  defined in RFC 2301.   This probably requires the definition of new
TIFF fields and a careful consideration of the relationship between the 
related fields.   

If a Fax WG or related IETF mailing list is available, this would be the
place 
to review such changes.   It would appear that revisions of this nature 
would require something like a  new TIFF extensions RFC.   

If no Fax WG is available, the specification work on extensions could
conceivably be done by another experts group  such as the ITU SG8.  
However, it would seem that at minimum there would need to be 
consultation with a designated IETF expert or related mailing list.  

Comments?   
 
>4) no change to feature schema is required; maybe just update T.30 mapping.
>
This is a simple case which can be done in either the IETF or the ITU by 
creating informative material (T.30 mapping, implementor's guide, or
ITU appendices).   

Comments?  
>
>The potential solutions were presented to the group, but further discussion
>is deferred to the list, due to time constraints.   After discussion, the
>chair will draft a response on this communication to the ITU for early
>September review by the WG.  
>
There are lots of issues here and not so much discussion so far
on the list.  Earlier, there were some comments on the list
wondering what this was all about.  Hopefully, these different examples
illustrate some practical ways to proceed.   .  

Please offer your comments.    

There is the matter of future cooperation between IETF and ITU
as both groups re-organize their activities going forward.   

I think we need to talk at least a little bit about this 
here on the list and possibly in the communication.  
Since the IETF/ITU cooperation has produced good
results,  it seems clear there will be value in keeping
a channel for communication open even if the current
Fax WG concludes its work.  Obviously, the details
on such a scenario have not yet been worked out.  

Since this has already gone on quite a bit, let's take 
that topic up in a separate thread.   Private comments are 
also welcome.  

James Rafferty
Chair, IETF Internet Fax WG

*------------------------------------------------*
James Rafferty			
President, Human Communications LLC
12 Kevin Drive			
Danbury, CT  06811-2901		
USA					
Voice/Fax:  +1-203-746-4367
Fax to email:  +1-603-925-5753  (Current Preferred Fax Number)
Email/Internet Fax:  [email-masked]
Alternate email : [email-masked],
 [email-masked] (chg from csi.com)

HC Web Site:  http://humancomm.com 
*---------------------------------------------------

---

From: Hiroshi Tamura <[email-masked]>
Date: Mon, 06 Sep 1999 15:34:37 +0900 (JST)

Rafferty-san,

<snip>

> consultation with a designated IETF expert or related mailing list.  

My concern is this FAX WG will close.

T.37 refers to lots of RFCs. Some of them are stable, but
Others may be extended.

From the ITU point of view, if ITU introduces new functions
in T.37 and there are no consultation points like this Fax WG,
what should ITU do ?

As we know this WG closes, I believe there should be some
descriptions in the response letter to ITU,
about the future correspondance between IETF and ITU.

> as both groups re-organize their activities going forward.   

Right. This is exactly what I would like to say.

> on such a scenario have not yet been worked out.  

Yes, we have good cooperation. As Mr. Zhao(Director of TSB
in ITU) said in IETF Oslo plenary, T.37 is one of the best examples
of collaboration between ITU and IETF.

Keeping channel is necessary.

Regards,

--
Hiroshi Tamura, Ricoh Company, LTD.
Mail: [email-masked]
Tel: +81-46-228-1743  Fax: +81-46-228-7500 (SUB/F-code 5727)

---

From: George Pajari <[email-masked]>
Date: Tue, 07 Sep 1999 20:55:30 -0700

>on the new tag numbers to avoid duplicate assignments.

Just a short technical note to say that there is an entirely legal method 
to extend TIFF without consultation with Adobe that will avoid duplicate 
tag number assignments. Not that I am suggesting that this is either 
necessary nor the appropriate approach but just to inform people of the 
options that are available.

Warning, unnecessarily detailed technical information follow...

The methodology for general extensions to TIFF is to obtain a (single) 
unique tag number from Adobe (anyone can request this, we have ten of them 
and have used them to extend TIFF for our own products to include fields 
such as sending TSI, DID info, receive duration, etc.).

Then use this tag not to store information directly but to point to a 
secondary directory structure within the TIFF file that contains your new 
tags. Since this secondary directory structure is only seen by software 
that knows it exists, one can use (and administer) the tag numbers in this 
secondary directory structure independently of Adobe without any risk of 
collision.

Of course, this is not an ideal solution since (a) it is less elegant than 
having a top-level tag number and (b) may result in redundant tags when the 
TIFF standard eventually defines a top-level tag that replicates the 
semantics of your second-level tag. But it can be done should it be 
appropriate or necessary for the IESG or ITU to manage extensions to TIFF 
independently from any other body (such as Adobe).

George Pajari
Propeller-Head Emeritus
Faximum Software Inc.