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

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

At 13:22 03/09/99 -0400, James  Rafferty wrote:

>>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.

I agree that some form of ongoing coordination is required.

But many new features (e.g. new resolutions) can be accommodated by the existing feature schema described in RFC 2531.

In the case of media feature registration, the IANA procedures already exist for registration of new features by non-IETF bodies.

As you noted, from RFC 2506, Media Feature Tag Registration Procedure:

>"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".  

Note that the citation [5] above is:

   [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
       Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

(The other registration trees are "global" and "URI", which do not seem especially relevant to standard Internet fax.)

>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.   
[...]
>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?   

For feature tags that are whose use is indicated by a standards-track protocol, I think the IETF tree would be more appropriate.

(But for private-use extensions to the framework (e.g. like T.30 NSF?) then I think the global tree would probably be appropriate.)

>>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.   

Actually, in the particular case of new resolutions, the only parts which would need to be changed are the examples which are non-normative:  the normative framework can already accommodate new resolution values.  Therefore, I think that the publication of a new informational document with updated examples would be sufficient (together with an update to the informational T.30 mapping document).

In this case, I think it is not necessary to re-issue the standards-track document.  (Of course, if there are other changes required to that document...)

>>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.   
[...]
>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.

>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.

>>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.

#g

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

---

From: MAEDA toru <[email-masked]>
Date: Wed, 08 Sep 1999 10:13:57 +0900

Klyne-san

I have some question about trees.

What is the difference between the IETF tree and the global tree?
Is this on the definition procedure?
Are ther any difference to refere or to use tags in the IETF tree and the 
global tree?

Cloud you teach me how to define tags for private-use extensions ?

Regards.

Toru MAEDA

At 10:59 99/09/07 +0100, Graham Klyne wrote:
> But many new features (e.g. new resolutions) can be accommodated by the 
existing feature schema described in RFC 2531.
> 
> In the case of media feature registration, the IANA procedures already 
exist for registration of new features by non-IETF bodies.
> (The other registration trees are "global" and "URI", which do not seem 
especially relevant to standard Internet fax.)
> For feature tags that are whose use is indicated by a standards-track 
protocol, I think the IETF tree would be more appropriate.
> 
> (But for private-use extensions to the framework (e.g. like T.30 NSF?) 
then I think the global tree would probably be appropriate.)
----------------------------
CANON INC.
TORU MAEDA
Technology Advancement Div. 3
3-30-2,Shimomaruko Ohtaku,Tokyo,Japan
E-mail    [email-masked] 
TEL  +81-3-3757-9738  FAX  +81-3-3757-8205
----------------------------