rfc2436.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

         regulatory connotations are concerned.

      - Reference should be made to the particular issue of a standard.
         In this way the ITU-T is in control of what is actually
         referenced even if the source organization updates the
         standard.
      - References to standards from other organizations should only be
         made where those organizations continue to provide public
         access to the version referenced even when updated versions are
         issued.
      - When a draft Recommendation is being prepared and the intention
         is to reference a standard from another organization, that
         organization should be advised by the TSB of the ITU-T's
         intention and should be requested to notify the ITU-T of any
         impending changes to the standard and of any reissues of the
         standard. (This request may be part of the correspondence
         described in Recommendation A.5, section 2.4.) It is however
         the responsibility of the Study Group to regularly review its
         Recommendations and check if the references are correct and if
         necessary to reissue the Recommendation with revised references
         (and where necessary make changes in the body of the
         Recommendation where the reference is made.).
      - Should an organization intend to remove completely an earlier
         version of a standard the ITU-T should be advised so that it
         can either incorporate the text in the Recommendation or change
         the reference to a later version.

   2. Access
      - The objective is to have referenced standards freely available
         via the Web so that people purchasing a Recommendation may get
         access to the references.  A warning should be given to
         purchasers of ITU-T Recommendations that they may have to



Brett, et. al.               Informational                     [Page 10]

RFC 2436            ISOC/IETF - ITU-T Collaboration         October 1998


         additionally purchase the referenced standards. This could be
         done by including a note to such effect in the introduction to
         Recommendations where references are included.
      - When developing a Recommendation where consideration is being
         given to using references to other standards the Study Group
         should investigate with the TSB whether the referenced text
         will be available free of charge or if a payment will be
         required. This should be taken into account by the Study Group
         as it may influence the decision to use the reference.

   3. IPR
      - In principle, if the IPR policy of the organization owning a
         referenced standard is more stringent than that of the ITU-T
         then there should not be any IPR problems with including the
         reference. However, this may not be the case with all
         organizations. Further guidelines are being prepared by the
         Director of the TSB.

   4. Approval
      - The approval procedures in Resolution 1 have to be followed for
         Recommendations containing references (wholly or in part) to
         standards from other bodies even in the case where the
         Recommendation is just a reference to another standard.

PART II - Developed by TSAG at its September 1998 Meeting

   The following guidelines should be used in conjunction with
   Recommendation A.5.

   1. Nested References
      Issue: RFCs often contain references to related RFCs and ITU-T
      Recommendations which, in turn, may contain references to other
      RFCs and Recommendations. It is unclear how to handle these nested
      references in the context of A.5.

      Guideline: Each time an RFC is referenced within an ITU-T
      Recommendation, all references within that RFC should be listed in
      the report documenting the decision of the Study Group. No further
      treatment is necessary, although the Study Group may wish to
      investigate those references further on a case-by-case basis. The
      same guidelines apply when referencing the documents of other
      organizations.

   2. Subsequent Referencing of the Same Document
      Issue: It is possible that the same RFC may be considered for
      referencing in multiple Recommendations. It is unclear what
      evaluation is required in subsequent references.




Brett, et. al.               Informational                     [Page 11]

RFC 2436            ISOC/IETF - ITU-T Collaboration         October 1998


      Guideline: The justification for referencing the same document in
      different Recommendations is likely to be different. Consequently,
      it is important that separate evaluations be made each time the
      document is referenced.  However, only items 1 - 8 in Appendix I
      (and Annex A) of Recommendation A.5 need to be completed if the
      referenced organization has already been qualified per Section 3
      of A.5. Since items 9 and 10 are dependent on the organization and
      not on the document, they need to be completed only the first time
      a document from that organization is being considered for
      referencing and only if such information has not been documented
      already.

   3. Availability of Referenced Document
      Issue: Paragraph 2.2.10 of A.5 requires that the contributing
      Study Group member provide a full copy of the existing document.
      It is unclear whether paper copies are mandatory or whether
      electronic availability, for example, on a Web site, is
      sufficient.

      Guideline: The objective is to have referenced documents available
      via the Web at no cost so that the Study Group members may proceed
      with their evaluation. Accordingly, if a referenced document is
      available in this manner, it is sufficient for the contributing
      member to provide its exact location on the Web. On the other
      hand, if the document is not available in this manner, a full copy
      must be provided (in electronic format if permissible by the
      referenced organization, otherwise in paper format).

   4. Referencing of IETF Documents
      Issue: It is unclear whether or not it is appropriate to reference
      RFCs that are not on the standards track (the "Informational" and
      "Experimental" RFCs) or those that are at the first level of
      standardization (the "Proposed Standard" RFCs).

      Guideline: Some outputs of organizations may not be appropriate
      for normative referencing, others may not be appropriate for any
      referencing, normative or informative. In the case of the IETF, it
      is not appropriate to make any references to "Internet Drafts" or
      to "Historic" RFCs as noted in A.5. In addition, it is not
      appropriate to make normative references to RFCs that are
      considered "Informational" or "Experimental". References to RFCs
      that have the status of "Proposed Standards" should be made with
      caution and should be evaluated on a case-by-case basis because
      such standards are considered immature in the sense that they may
      change if problems are found in real implementations or if better
      solutions are identified.





Brett, et. al.               Informational                     [Page 12]

RFC 2436            ISOC/IETF - ITU-T Collaboration         October 1998


   5. IETF Address Changes
      The electronic address of the IETF archives has changed.
      Accordingly the addresses in items 4 and 9.8 of Annex A should be
      changed, respectively to:
         http://www.ietf.org/ipr.html - for the IPR archive
         http://www.rfc-editor.org/rfc.html - for the RFC archive













































Brett, et. al.               Informational                     [Page 13]

RFC 2436            ISOC/IETF - ITU-T Collaboration         October 1998


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Brett, et. al.               Informational                     [Page 14]