rfc2418.txt

RFC 的详细文档！

   general, in-depth review.

   The IESG review takes into account responses to the Last-Call and
   will lead to one of these possible conclusions:





Bradner                  Best Current Practice                 [Page 21]

RFC 2418                Working Group Guidelines          September 1998


   1. The document is accepted as is for the status requested.
      This fact will be announced by the IETF Secretariat to the IETF
      mailing list and to the RFC Editor.

   2. The document is accepted as-is but not for the status requested.
      This fact will be announced by the IETF Secretariat to the IETF
      mailing list and to the RFC Editor (see [1] for more details).

   3. Changes regarding content are suggested to the author(s)/WG.
      Suggestions from the IESG must be clear and direct, so as to
      facilitate working group and author correction of the
      specification.  If the author(s)/WG can explain to the
      satisfaction of the IESG why the changes are not necessary, the
      document will be accepted for publication as under point 1, above.
      If the changes are made the revised document may be resubmitted
      for IESG review.

   4. Changes are suggested by the IESG and a change in status is
      recommended.
      The process described above for 3 and 2 are followed in that
      order.

   5. The document is rejected.
      Any document rejection will be accompanied by specific and
      thorough arguments from the IESG. Although the IETF and working
      group process is structured such that this alternative is not
      likely to arise for documents coming from a working group, the
      IESG has the right and responsibility to reject documents that the
      IESG feels are fatally flawed in some way.

      If any individual or group of individuals feels that the review
      treatment has been unfair, there is the opportunity to make a
      procedural complaint. The mechanism for this type of complaints is
      described in [1].

9. Security Considerations

   Documents describing IETF processes, such as this one, do not have an
   impact on the security of the network infrastructure or of Internet
   applications.

   It should be noted that all IETF working groups are required to
   examine and understand the security implications of any technology
   they develop.  This analysis must be included in any resulting RFCs
   in a Security Considerations section.  Note that merely noting a
   significant security hole is no longer sufficient.  IETF developed
   technologies should not add insecurity to the environment in which
   they are run.



Bradner                  Best Current Practice                 [Page 22]

RFC 2418                Working Group Guidelines          September 1998


10. Acknowledgments

   This revision of this document relies heavily on the previous version
   (RFC 1603) which was edited by Erik Huizer and Dave Crocker.  It has
   been reviewed by the Poisson Working Group.

11. References

   [1] Bradner, S., Editor, "The Internet Standards Process -- Revision
       3", BCP 9, RFC 2026, October 1996.

   [2] Hovey, R., and S. Bradner, "The Organizations involved in the
       IETF Standards Process", BCP 11, RFC 2028, October 1996.

   [3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall
       Process: Operation of the Nominating and Recall Committees", BCP
       10, RFC 2282, February 1998.

   [4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards",
       RFC 1796, April 1995.

   [5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC
       2223, October 1997.

   [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Level", BCP 14, RFC 2119, March 1997.


12. Editor's Address

   Scott Bradner
   Harvard University
   1350 Mass Ave.
   Cambridge MA
   02138
   USA

   Phone [phone]
   EMail: [e-mail]












Bradner                  Best Current Practice                 [Page 23]

RFC 2418                Working Group Guidelines          September 1998


   Appendix:  Sample Working Group Charter

   Working Group Name:
        IP Telephony (iptel)

   IETF Area:
        Transport Area

   Chair(s):
        Jonathan Rosenberg <[e-mail]>

   Transport Area Director(s):
        Scott Bradner <[e-mail]>
        Allyn Romanow <[e-mail]>

   Responsible Area Director:
        Allyn Romanow <[e-mail]>

   Mailing Lists:
        General Discussion:[e-mail]
        To Subscribe: [e-mail]
        Archive: http://www.bell-labs.com/mailing-lists/siptel

   Description of Working Group:

   Before Internet telephony can become a widely deployed service, a
   number of protocols must be deployed. These include signaling and
   capabilities exchange, but also include a number of "peripheral"
   protocols for providing related services.

   The primary purpose of this working group is to develop two such
   supportive protocols and a frameword document. They are:

   1. Call Processing Syntax. When a call is setup between two
   endpoints, the signaling will generally pass through several servers
   (such as an H.323 gatekeeper) which are responsible for forwarding,
   redirecting, or proxying the signaling messages. For example, a user
   may make a call to [e-mail]. The signaling message to
   initiate the call will arrive at some server at bigcompany. This
   server can inform the caller that the callee is busy, forward the
   call initiation request to another server closer to the user, or drop
   the call completely (among other possibilities). It is very desirable
   to allow the callee to provide input to this process, guiding the
   server in its decision on how to act. This can enable a wide variety
   of advanced personal mobility and call agent services.






Bradner                  Best Current Practice                 [Page 24]

RFC 2418                Working Group Guidelines          September 1998


   Such preferences can be expressed in a call processing syntax, which
   can be authored by the user (or generated automatically by some
   tool), and then uploaded to the server. The group will develop this
   syntax, and specify means of securely transporting and extending it.
   The result will be a single standards track RFC.

   2. In addition, the group will write a service model document, which
   describes the services that are enabled by the call processing
   syntax, and discusses how the syntax can be used. This document will
   result in a single RFC.

   3. Gateway Attribute Distribution Protocol. When making a call
   between an IP host and a PSTN user, a telephony gateway must be used.
   The selection of such gateways can be based on many criteria,
   including client expressed preferences, service provider preferences,
   and availability of gateways, in addition to destination telephone
   number.  Since gateways outside of the hosts' administrative domain
   might be used, a protocol is required to allow gateways in remote
   domains to distribute their attributes (such as PSTN connectivity,
   supported codecs, etc.) to entities in other domains which must make
   a selection of a gateway. The protocol must allow for scalable,
   bandwidth efficient, and very secure transmission of these
   attributes. The group will investigate and design a protocol for this
   purpose, generate an Internet Draft, and advance it to RFC as
   appropriate.

   Goals and Milestones:

   May 98    Issue first Internet-Draft on service framework
   Jul 98    Submit framework ID to IESG for publication as an RFC.
   Aug 98    Issue first Internet-Draft on Call Processing Syntax
   Oct 98    Submit Call processing syntax to IESG for consideration
             as a Proposed Standard.
   Dec 98    Achieve consensus on basics of gateway attribute
             distribution protocol
   Jan 99    Submit Gateway Attribute Distribution protocol to IESG
             for consideration as a RFC (info, exp, stds track TB














Bradner                  Best Current Practice                 [Page 25]

RFC 2418                Working Group Guidelines          September 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.
























Bradner                  Best Current Practice                 [Page 26]