IPP> FW: FW: ADM - Questions on Backwards Compatibility betwe en IPP/1. 0 an d IPP/1.1

IPP> FW: FW: ADM - Questions on Backwards Compatibility betwe en IPP/1. 0 an d IPP/1.1

IPP> FW: FW: ADM - Questions on Backwards Compatibility betwe en IPP/1. 0 an d IPP/1.1

Hastings, Tom N hastings at cp10.es.xerox.com
Mon May 17 17:55:55 EDT 1999

I've attached section 9.1 that Keith refers to.  So we have to write an I-D
explaining why we want to have the normative reference to the Experimental
RFCs 2565 and 2566.  Carl-Uno and I will draft such an I-D.


-----Original Message-----
From: Keith Moore [mailto:moore at cs.utk.edu]
Sent: Monday, May 17, 1999 11:14
To: Hastings, Tom N
Cc: moore at cs.utk.edu; IETF-IPP
Subject: Re: IPP> FW: FW: ADM - Questions on Backwards Compatibility
betwe en IPP/1. 0 an d IPP/1.1 

> Is this a "normative" reference or not?

SHOULD is a normative reference.

Requesting a variance is the easiest way to fix this.
The variance procedure is documented in RFC 2026, section 9.1.


Here is section 9.1:

9.1 The Variance Procedure

   Upon the recommendation of the responsible IETF Working Group (or, if
   no Working Group is constituted, upon the recommendation of an ad hoc
   committee), the IESG may enter a particular specification into, or
   advance it within, the standards track even though some of the
   requirements of this document have not or will not be met. The IESG
   may approve such a variance, however, only if it first determines
   that the likely benefits to the Internet community are likely to
   outweigh any costs to the Internet community that result from
   noncompliance with the requirements in this document.  In exercising
   this discretion, the IESG shall at least consider (a) the technical
   merit of the specification, (b) the possibility of achieving the
   goals of the Internet Standards Process without granting a variance,
   (c) alternatives to the granting of a variance, (d) the collateral
   and precedential effects of granting a variance, and (e) the IESG's
   ability to craft a variance that is as narrow as possible.  In
   determining whether to approve a variance, the IESG has discretion to
   limit the scope of the variance to particular parts of this document
   and to impose such additional restrictions or limitations as it

Bradner                  Best Current Practice                 [Page 27]
RFC 2026               Internet Standards Process           October 1996

   determines appropriate to protect the interests of the Internet

   The proposed variance must detail the problem perceived, explain the
   precise provision of this document which is causing the need for a
   variance, and the results of the IESG's considerations including
   consideration of points (a) through (d) in the previous paragraph.
   The proposed variance shall be issued as an Internet Draft.  The IESG
   shall then issue an extended Last-Call, of no less than 4 weeks, to
   allow for community comment upon the proposal.

   In a timely fashion after the expiration of the Last-Call period, the
   IESG shall make its final determination of whether or not to approve
   the proposed variance, and shall notify the IETF of its decision via
   electronic mail to the IETF Announce mailing list.  If the variance
   is approved it shall be forwarded to the RFC Editor with a request
   that it be published as a BCP.

   This variance procedure is for use when a one-time waving of some
   provision of this document is felt to be required.  Permanent changes
   to this document shall be accomplished through the normal BCP

   The appeals process in section 6.5 applies to this process.

More information about the Ipp mailing list