rfc3117.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,516 行 · 第 1/4 页

   implement BXXP.)

5.4 Authentication

   We use SASL.  If you successfully authenticate using a channel, then
   there is a single user identity for each peer on that session (i.e.,
   authentication is per-session, not per-channel).  This design
   decision mandates that each session correspond to a single user
   regardless of how many channels are open on that session.  One reason
   why this is important is that it allows service provisioning, such as
   quality of service (e.g., as in [34]) to be done on a per-user
   granularity.

5.5 Privacy

   We use SASL and TLS.  If you successfully complete a transport
   security negotiation using a channel, then all traffic on that
   session is secured (i.e., confidentiality is per-session, not per-
   channel, just like authentication).

   We defined a BXXP profile that's used to start the TLS engine.

5.6 Things We Left Out

   We purposefully excluded two things that are common to most
   application protocols: naming and authorization.

   Naming was excluded from the framework because, outside of URIs,
   there isn't a commonly accepted framework for naming things.  To our
   view, this remains a domain-specific problem for each application
   protocol.  Maybe URIs are appropriate in the context of a
   particularly problem domain, maybe not.  So, when an application
   protocol designer defines their own profile to do "the useful work",
   they'll have to deal with naming issues themselves.  BXXP provides a
   mechanism for identifying profiles and binding them to channels. It's
   up to you to define the profile and use the channel.




Rose                         Informational                     [Page 21]

RFC 3117         On the Design of Application Protocols    November 2001


   Similarly, authorization was explicitly excluded from the framework.
   Every approach to authorization we've seen uses names to identify
   principals (i.e., targets and subjects), so if a framework doesn't
   include naming, it can't very well include authorization.

   Of course, application protocols do have to deal with naming and
   authorization -- those are two of the issues addressed by the
   applications protocol designer when defining a profile for use with
   BXXP.

5.7 From Framework to Protocol

   So, how do you go about using BXXP? To begin, call it "BEEP", not
   "BXXP" (we'll explain why momentarily).

   First, get the BEEP core specification [35] and read it.  Next,
   define your own profile.  Finally, get one of the open source SDKs
   (in C, Java, or Tcl) and start coding.

   The BEEP specification defines several profiles itself: a channel
   management profile, a family of profiles for SASL, and a transport
   security profile.  In addition, there's a second specification [36]
   that explains how a BEEP session maps onto a single TCP connection.

   For a complete example of an application protocol defined using BEEP,
   look at reliable syslog [37].  This document exemplifies the formula:

   application protocol = BEEP + 1 or more profiles
                        + authorization policies
                        + provisioning rules (e.g., use of SRV RRs [38])





















Rose                         Informational                     [Page 22]

RFC 3117         On the Design of Application Protocols    November 2001


6. BXXP is now BEEP

   We started work on BXXP in the fall of 1998.  The IETF formed a
   working group on BXXP in the summer of 2000.  Although the working
   group made some enhancements to BXXP, three are the most notable:

   o  The payload default is "application/octet-stream".  This is
      primarily for wire-efficiency -- if you care about wire-
      efficiency, then you probably wouldn't be using "text/xml"...

   o  One-to-many exchanges are supported (the client sends one message
      and the server sends back many replies).

   o  BXXP is now called BEEP (more comic possibilities).

7. Security Considerations

   Consult Section [35]'s Section 8 for a discussion of BEEP-related
   security issues.
































Rose                         Informational                     [Page 23]

RFC 3117         On the Design of Application Protocols    November 2001


References

   [1]   Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
         August 1982.

   [2]   Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
         RFC 959, October 1985.

   [3]   Berners-Lee, T., Fielding, R. and H. Nielsen, "Hypertext
         Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

   [4]   Herriot, R., "Internet Printing Protocol/1.0: Encoding and
         Transport", RFC 2565, April 1999.

   [5]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part One: Format of Internet Message Bodies",
         RFC 2045, November 1996.

   [6]   Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
         Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

   [7]   Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
         September 1981.

   [8]   Mockapetris, P., "Domain names - concepts and facilities", STD
         13, RFC 1034, November 1987.

   [9]   Microsystems, Sun., "NFS: Network File System Protocol
         specification", RFC 1094, March 1989.

   [10]  Srisuresh, P. and M. Holdrege, "IP Network Address Translator
         (NAT) Terminology and Considerations", RFC 2663, August 1999.

   [11]  Crocker, D., "Standard for the format of ARPA Internet text
         messages", STD 11, RFC 822, August 1982.

   [12]  Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
         2.0", RFC 1866, November 1995.

   [13]  Freed, N., "SMTP Service Extension for Returning Enhanced Error
         Codes", RFC 2034, October 1996.

   [14]  Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
         December 1994.

   [15]  Freed, N., "SMTP Service Extension for Command Pipelining", RFC
         2197, September 1997.



Rose                         Informational                     [Page 24]

RFC 3117         On the Design of Application Protocols    November 2001


   [16]  Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer
         Protocol", RFC 2660, August 1999.

   [17]  Myers, J., "Simple Authentication and Security Layer (SASL)",
         RFC 2222, October 1997.

   [18]  Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
         October 1998.

   [19]  Myers, J., "SMTP Service Extension for Authentication", RFC
         2554, March 1999.

   [20]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
         Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
         Basic and Digest Access Authentication", RFC 2617, June 1999.

   [21]  Kent, S. and R. Atkinson, "Security Architecture for the
         Internet Protocol", RFC 2401, November 1998.

   [22]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
         2246, January 1999.

   [23]  Newman, C. and J. Myers, "ACAP -- Application Configuration
         Access Protocol", RFC 2244, November 1997.

   [24]  Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS",
         RFC 2487, January 1999.

   [25]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
         June 1999.

   [26]  Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
         53, RFC 1939, May 1996.

   [27]  Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
         Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,
         C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J.
         and L. Zhang, "Recommendations on Queue Management and
         Congestion Avoidance in the Internet", RFC 2309, April 1998.

   [28]  Touch, J., "TCP Control Block Interdependence", RFC 2140, April
         1997.

   [29]  Postel, J. and J. Reynolds, "Telnet Protocol Specification",
         STD 8, RFC 854, May 1983.






Rose                         Informational                     [Page 25]

RFC 3117         On the Design of Application Protocols    November 2001


   [30]  World Wide Web Consortium, "Extensible Markup Language (XML)
         1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-
         xml-19980210>.

   [31]  Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple
         Network Management Protocol (SNMP)", STD 15, RFC 1157, May
         1990.

   [32]  World Wide Web Consortium, "SMUX Protocol Specification",
         Working Draft, July 1998, <http://www.w3.org/TR/1998/WD-mux-
         19980710>.

   [33]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396, August
         1998.

   [34]  Waitzman, D., "IP over Avian Carriers with Quality of Service",
         RFC 2549, April 1999.

   [35]  Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
         3080, March 2001.

   [36]  Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
         2001.

   [37]  New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195,
         November 2001.

   [38]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
         specifying the location of services (DNS SRV)", RFC 2782,
         February 2000.

   [39]  <http://mappa.mundi.net/cartography/Wheel/>

Author's Address

   Marshall T. Rose
   Dover Beach Consulting, Inc.
   POB 255268
   Sacramento, CA  95865-5268
   US

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







Rose                         Informational                     [Page 26]

RFC 3117         On the Design of Application Protocols    November 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Rose                         Informational                     [Page 27]