rfc1603.txt

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

   The work of an IETF working group usually results in publication of
   one or more documents, as part of the Request For Comments (RFCs) [2]
   series. This series is the archival publication record for the
   Internet community. A document can be written by an individual in a
   working group, by a group as a whole with a designated Editor, or by
   others not involved with the IETF. The designated author need not be
   the group Chair(s).

   NOTE:  The RFC series is a publication mechanism only and publication
   does not determine the IETF status of a document.  Status is
   determined through separate, explicit status labels assigned by the
   IESG on behalf of the IETF.  In other words, the reader is reminded
   that all Internet Standards are published as RFCs, but NOT all RFCs
   specify standards.

   For a description on the various categories of RFCs the reader is
   referred to [1, 4, 5, 6].

6.5. Submission of documents

   When a WG decides that a document is ready for publication, the
   following must be done:

   -    The version of the relevant document as approved by the WG
        must be in the Internet-Drafts directory;

   -    The relevant document must be formatted according to RFC
        rules [2].

   -    The WG Chair sends email to the relevant Area Director, with
        a copy to the IESG Secretary.  The mail should contain the
        reference to the document, and the request that it be
        progressed as an Informational, Experimental, Prototype or
        standards-track (Proposed, Draft or Internet Standard) RFC.

   The IESG Secretary will acknowledge receipt of the email.  Unless
   returned to the WG for further development, progressing of the



Huizer & Crocker                                               [Page 24]

RFC 1603             IETF Working Group Guidelines            March 1994


   document is then the responsibility of the IESG.  After IESG
   approval, responsibility for final disposition is the joint
   responsibility of the RFC Editor and the WG Chair and Editor.

6.6. Review of documents

   Usually in case of a submission intended as an Informational or
   Experimental RFC minimal review is necessary. However, if the WG or
   the RFC Editor thinks that an extensive review is appropriate, the
   Area Director may be asked to conduct one. This review may either be
   done by the AD and other IESG participants or the IESG may ask for an
   independent review (e.g., by someone not part of the WG in question)
   from the Area Directorate or elsewhere.

   A review will lead to one of three possible conclusions:

   1.   The document is accepted as is.

        This fact will be announced by the IESG Secretary to the
        IETF mailing list and to the RFC Editor. Publication is then
        further handled between the RFC Editor and the author(s).

   2.   Changes regarding content are suggested to the author(s)/WG.

        Suggestions must be clear and direct, so as to facilitate
        working group and author correction of the specification.
        Once the author(s)/WG have made these changes or have
        explained to the satisfaction of the reviewers why the
        changes are not necessary, the document will be accepted for
        publication as under point 1, above.

   3.   The document is rejected.

        This will need strong and thorough arguments from the
        reviewers. The whole IETF and working group process is
        structured such that this alternative is not likely to arise
        for documents coming from a working group. After all, the
        intentions of the document will already have been described
        in the WG charter, and reviewed at the start of the WG.

   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 procedural complaints is
   described in the section on Contention and Appeal.

   Before the IESG makes a final decision on a standards-track document,
   the IESG Secretary will issue a "Last Call" to the IETF mailing list.
   This Last Call will announce the intention of the IESG to consider



Huizer & Crocker                                               [Page 25]

RFC 1603             IETF Working Group Guidelines            March 1994


   the document, and it will solicit final comments from the IETF within
   a period of two weeks.  It is important to note that a Last Call is
   intended as a brief, final check with the Internet community, to make
   sure that no important concerns have been missed or misunderstood.
   The Last Call cannot serve as a more general, in-depth review.

7.  SECURITY CONSIDERATIONS

   Security issues are not discussed in this memo.

8.  REFERENCES

   [1] Internet Architecture Board and Internet Engineering Steering
       Group, "The Internet Standards Process -- Revision 2", RFC 1602,
       IAB, IESG, March 1994.

   [2] Postel, J., "Instructions to RFC Authors", RFC 1543,
       USC/Information Sciences Institute, October 1993.

   [3] Malkin, G., and J. Reynolds, "F.Y.I. on F.Y.I. - Introduction to
       the F.Y.I. Notes", RFC 1150, Proteon, USC/Information Sciences
       Institute, March 1990.

   [4] Postel, J., Editor, "Introduction to the STD Notes", RFC 1311,
       USC/Information Sciences Institute, March 1992.

   [5] Postel, J., Editor, "Internet Official Protocol Standards", STD
       1, RFC 1600, IAB, March 1994.

   [6] Cerf, V., "The Internet Activities Board", RFC 1160, NRI, May
       1990.




















Huizer & Crocker                                               [Page 26]

RFC 1603             IETF Working Group Guidelines            March 1994


9.  AUTHORS' ADDRESSES

       Erik Huizer
       SURFnet bv
       P.O. Box 19035
       3501 DA  Utrecht
       The Netherlands

       Phone: [phone]
       Fax: [phone]
       EMail: [e-mail]


       Dave Crocker
       Silicon Graphics, Inc.
       2011 N. Shoreline Blvd.
       P.O. Box 7311
       Mountain View, CA 94039

       Phone: [phone]
       Fax: [phone]
       EMail: [e-mail]





























Huizer & Crocker                                               [Page 27]

RFC 1603             IETF Working Group Guidelines            March 1994


APPENDIX:  SAMPLE WORKING GROUP CHARTER

       Multiparty Multimedia Session Control (mmusic)

        Charter

        Chair(s):
            Eve Schooler  <[e-mail]>
            Abel Weinrib  <[e-mail]>

        Transport Area Director(s)
            Allison Mankin  <[e-mail]>

        Mailing lists:
            General Discussion:[e-mail]
            To Subscribe:      [e-mail]
            Archive:           venera.isi.edu:~/confctrl/confcrtl.mail

       Description of Working Group:

       The demand for Internet teleconferencing has arrived, yet an
       infrastructure to support this demand is barely in place.
       Multimedia session control, defined as the management and
       coordination of multiple sessions and their multiple users in
       multiple media (e.g., audio, video), is one component of the
       infrastructure.  The Multiparty Multimedia Session Control
       Working Group is chartered to design and specify a protocol to
       perform these functions.

       The protocol will provide negotiation for session membership,
       underlying communication topology and media configuration.  In
       particular, the protocol will support a user initiating a
       multimedia multiparty session with other users ("calling" other
       users) over the Internet by allowing a teleconferencing
       application on one workstation to explicitly rendezvous with
       teleconferencing applications running on remote workstations.
       Defining a standard protocol will enable session-level
       interoperability between different teleconferencing
       implementations.

       The focus of the working group is to design a session negotiation
       protocol that is tailored to support tightly-controlled
       conferences.  The MBONE currently carries primarily loosely-
       controlled sessions, i.e., sessions with little to no interaction
       among members and with no arbitration facility, security, or
       coordination of quality-of-service options for time-critical
       media.  Users may learn of available sessions using the "sd"
       utility or other out of band mechanisms (e.g., email).  However,



Huizer & Crocker                                               [Page 28]

RFC 1603             IETF Working Group Guidelines            March 1994


       there is clearly also a need for tightly-controlled sessions that
       provide mechanisms for directly contacting other users to
       initiate a session and for negotiating conference parameters such
       as membership, media encodings and encryption keys.  In addition,
       these sessions should support renegotiation during a session, for
       example to add or delete members or change the media encoding.
       It is possible that the protocol will, in the limiting case, also
       support loosely-controlled sessions.

       The main goal of the working group will be to specify the session
       control protocol for use within teleconferencing software over
       the Internet.  The working group will focus on the aspects of the
       session control problem that are well understood, while keeping
       an eye on evolving research issues.  Toward this end, the working
       group has made an inventory of existing conferencing systems and
       their session control protocols.  The working group will document
       the requirements of the existing prototypes as a basis for the
       protocol development.  The working group will iteratively refine
       the protocol based on implementation and operational experience.

       Furthermore, the working group will coordinate with other efforts
       related to multimedia conferencing, such as directory services
       for cataloguing users and conferences, the RTP and RTCP protocols
       developed by the Audio/Video Transport Working Group, resource
       reservation and management at the network level, and schemes for
       multicast address allocation.

       Goals and Milestones:

            May 93     Hold an on-line working group meeting to discuss
                       the conference control framework, the relevant
                       terminology, a functional taxonomy and how
                       different conversational styles place
                       requirements on session protocols.

            Jun 93     Submit the Conference Session Control Protocol to
                       the IESG for consideration as an Experimental
                       Protocol.

            Aug 93     Post an Internet-Draft describing the Session
                       Control Requirements.

            Nov 93     Post an Internet-Draft of the Session Control
                       Protocol.

            Mar 94     Submit a revised Internet-Draft based on
                       implementation experience.




Huizer & Crocker                                               [Page 29]