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

From: Graham Klyne <[email-masked]>
Date: Tue, 07 Sep 1999 11:00:10 +0100

At 15:34 06/09/99 +0900, Hiroshi Tamura wrote:
[...]
>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.

I'm sure James will be able to answer this more authoritatively, but I
think it needs to be said clearly that...

The IETF does not currently have a specific documented mechanism for
ongoing coordination with another body.  This is needed for Ifax and other
activities, and the definition of such process is something that will be
need to be initiated and ratified with IESG involvement.  I understand that
discussions with IESG are already taking place.

So, you are right:  we need a clear method for dealing with such issues.
But the full definition of such method lies outside the fax WG alone.

#g

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

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Tue, 7 Sep 1999 10:25:29 -0700

I am sticking my head above the water-line for only a few seconds to comment
here.

Lloyd

> -----Original Message-----
> From:	Graham Klyne [SMTP:[email-masked]]
> Sent:	Tuesday, September 07, 1999 3:00 AM
> To:	James Rafferty
> Cc:	Ietf-Fax
> Subject:	Re: Call for Discussion on Response to Communication 2 from
> ITU
> 
> At 13:22 03/09/99 -0400, James  Rafferty wrote:
> 
> ---snip---
> >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.   
> [...]
> >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?   
> 
> Given the importance of those field descriptions from RFC2301 when
> preparing the T.30 mapping document, I agree with the above.
> 
[McIntyre, Lloyd]  I will add my support.

> >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?   
> 
> If the result is to be referenced by the Internet fax standard documents,
> then I think they should be published as standards-track RFCs, either
> updating or replacing RFC 2301.
[McIntyre, Lloyd]  I absolutely agree.

> >>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?  
> 
> My hope is that this simple case would be the most common.
[McIntyre, Lloyd]  It may be the most common, however, as James has state -
there are significant changes over them there hills.