draft-ietf-beep-framework-08.txt   draft-ietf-beep-framework-09.txt 
Network Working Group M.T. Rose Network Working Group M.T. Rose
Internet-Draft Invisible Worlds, Inc. Internet-Draft Invisible Worlds, Inc.
Expires: May 14, 2001 November 13, 2000 Expires: June 16, 2001 December 16, 2000
The Blocks Extensible Exchange Protocol Framework The Blocks Extensible Exchange Protocol Framework
draft-ietf-beep-framework-08 draft-ietf-beep-framework-09
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 14, 2001. This Internet-Draft will expire on June 16, 2001.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract Abstract
This memo describes a generic application protocol framework for This memo describes a generic application protocol framework for
connection-oriented, asynchronous interactions. The framework connection-oriented, asynchronous interactions. The framework
permits simultaneous and independent exchanges within the context of permits simultaneous and independent exchanges within the context of
skipping to change at page 7, line 26 skipping to change at page 7, line 26
Normally, a message is sent in a single frame. However, it may be Normally, a message is sent in a single frame. However, it may be
convenient or necesary to segment a message into multiple frames convenient or necesary to segment a message into multiple frames
(e.g., if only part of a message is ready to be sent). (e.g., if only part of a message is ready to be sent).
Each frame consists of a header, the payload, and a trailer. The Each frame consists of a header, the payload, and a trailer. The
header and trailer are each represented using printable ASCII header and trailer are each represented using printable ASCII
characters and are terminated with a CRLF pair. Between the header characters and are terminated with a CRLF pair. Between the header
and the trailer is the payload, consisting of zero or more octets. and the trailer is the payload, consisting of zero or more octets.
For example, here is a message contained in a single frame that For example, here is a message contained in a single frame that
contains a payload of 119 octets spread over 5 lines (each line is contains a payload of 132 octets spread over 5 lines (each line is
terminated with a CRLF pair): terminated with a CRLF pair):
C: MSG 0 1 . 52 132 C: MSG 0 1 . 52 132
C: Content-Type: application/beep+xml C: Content-Type: application/beep+xml
C: C:
C: <start number='1'> C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
C: </start> C: </start>
C: END C: END
skipping to change at page 9, line 31 skipping to change at page 9, line 31
decimal code 46, ".") specifies whether this is the final frame of decimal code 46, ".") specifies whether this is the final frame of
the message: the message:
intermediate ("*"): at least one other frame follows for the intermediate ("*"): at least one other frame follows for the
message; or, message; or,
complete ("."): this frame completes the message. complete ("."): this frame completes the message.
The sequence number ("seqno") must be a non-negative integer (in the The sequence number ("seqno") must be a non-negative integer (in the
range 0..4294967295) and specifies the sequence number of the first range 0..4294967295) and specifies the sequence number of the first
octet in the payload, for the associated channel. octet in the payload, for the associated channel (c.f., Section
2.2.1.2).
The payload size ("size") must be a non-negative integer (in the The payload size ("size") must be a non-negative integer (in the
range 0..2147483647) and specifies the exact number of octets in the range 0..2147483647) and specifies the exact number of octets in the
payload. (This does not include either the header or trailer.) payload. (This does not include either the header or trailer.)
Note that a frame may have an empty payload, e.g., Note that a frame may have an empty payload, e.g.,
S: RPY 0 1 * 287 20 S: RPY 0 1 * 287 20
S: ... S: ...
S: ... S: ...
skipping to change at page 29, line 16 skipping to change at page 29, line 16
When a BEEP session is established, plaintext transfer, without When a BEEP session is established, plaintext transfer, without
privacy, is provided. Accordingly, transport security in BEEP is privacy, is provided. Accordingly, transport security in BEEP is
achieved using an initial tuning profile. achieved using an initial tuning profile.
This document defines one profile: This document defines one profile:
o the TLS transport security profile, based on TLS version one[3]. o the TLS transport security profile, based on TLS version one[3].
Other profiles may be defined and deployed on a bilateral basis. Other profiles may be defined and deployed on a bilateral basis.
Note that because of their intimate relationship with the tranpsort Note that because of their intimate relationship with the transport
service, a given transport security profile tends to be relevant to service, a given transport security profile tends to be relevant to
a single transort mapping (c.f., Section 2.5). a single transport mapping (c.f., Section 2.5).
When a channel associated with transport security begins the When a channel associated with transport security begins the
underlying negotiation process, all channels (including channel underlying negotiation process, all channels (including channel
zero) are closed on the BEEP session. Accordingly, upon completion zero) are closed on the BEEP session. Accordingly, upon completion
of the negotiation process, regardless of its outcome, a new of the negotiation process, regardless of its outcome, a new
greeting is issued by both BEEP peers. (If the negotiation process greeting is issued by both BEEP peers. (If the negotiation process
fails, then either BEEP peer may instead terminate the session, and fails, then either BEEP peer may instead terminate the session, and
it is recommended that a diagnostic entry be logged.) it is recommended that a diagnostic entry be logged.)
A BEEP peer may choose to issue different greetings based on whether A BEEP peer may choose to issue different greetings based on whether
skipping to change at page 34, line 16 skipping to change at page 34, line 16
3.1.3.1 The Ready Message 3.1.3.1 The Ready Message
The "ready" element has an optional "version" attribute and no The "ready" element has an optional "version" attribute and no
content: content:
o the "version" element defines the earliest version of TLS o the "version" element defines the earliest version of TLS
acceptable for use. acceptable for use.
When a BEEP peer sends the "ready" element, it must not send any When a BEEP peer sends the "ready" element, it must not send any
further traffic on any channel until a corresponding reply is further traffic on the underlying transport service until a
received; similarly, before processing a "ready" element, the corresponding reply ("proceed" or "error") is received; similarly,
receiving BEEP peer waits until any pending replies have been the receiving BEEP peer must wait until any pending replies have
generated and sent. been generated and sent before it processes a "ready" element.
3.1.3.2 The Proceed Message 3.1.3.2 The Proceed Message
The "proceed" element has no attributes and no content. It is sent The "proceed" element has no attributes and no content. It is sent
as a reply to the "ready" element. When a BEEP peer receives the as a reply to the "ready" element.
"ready" element, it begins the underlying negotiation process for
transport security. When a BEEP peer receives the "ready" element, it must not send any
further traffic on the underlying transport service until it
generates a corresponding reply. If the BEEP peer decides to allow
transport security negotation, it implicitly closes all channels
(including channel zero), and sends the "proceed" element, and
awaits the underlying negotiation process for transport security.
When a BEEP peer receives a "proceed" element in reply to its
"ready" message, it implicitly closes all channels (including
channel zero), and immediately begins the underlying negotiation
process for transport security.
4. User Authentication 4. User Authentication
When a BEEP session is established, anonymous access, without trace When a BEEP session is established, anonymous access, without trace
information, is provided. Accordingly, user authentication in BEEP information, is provided. Accordingly, user authentication in BEEP
is achieved using an initial tuning profile. is achieved using an initial tuning profile.
This document defines a family of profiles based on SASL mechanisms: This document defines a family of profiles based on SASL mechanisms:
o each mechanism in the IANA SASL registry[15] has an associated o each mechanism in the IANA SASL registry[15] has an associated
skipping to change at page 46, line 33 skipping to change at page 46, line 33
====== ================ ======= ====== ================ =======
a channel number a channel number
CHAN 1..2147483647 1 CHAN 1..2147483647 1
authoritative profile identification authoritative profile identification
URI c.f., [RFC-2396] http://invisible.net/ URI c.f., [RFC-2396] http://invisible.net/
one or more feature tokens, seperated by space one or more feature tokens, seperated by space
FTRS NMTOKENS "magic" FTRS NMTOKENS "magic"
zero or more language tags
LOCS NMTOKENS "en-US"
a language tag a language tag
LANG c.f., [RFC-1766] "en", "en-US", etc. LANG c.f., [RFC-1766] "en", "en-US", etc.
zero or more language tags
LOCS NMTOKENS "en-US"
a 3-digit reply code a 3-digit reply code
XYZ [1-5][0-9][0-9] 500 XYZ [1-5][0-9][0-9] 500
--> -->
<!ENTITY % CHAN "CDATA"> <!ENTITY % CHAN "CDATA">
<!ENTITY % URI "CDATA"> <!ENTITY % URI "CDATA">
<!ENTITY % FTRS "NMTOKENS"> <!ENTITY % FTRS "NMTOKENS">
<!ENTITY % LOCS "NMTOKEN">
<!ENTITY % LANG "NMTOKEN"> <!ENTITY % LANG "NMTOKEN">
<!ENTITY % LOCS "NMTOKEN">
<!ENTITY % XYZ "CDATA"> <!ENTITY % XYZ "CDATA">
<!-- <!--
BEEP messages, exchanged as application/beep+xml BEEP messages, exchanged as application/beep+xml
role MSG RSP ERR role MSG RSP ERR
======= === === === ======= === === ===
I and L greeting error I and L greeting error
I or L start profile error I or L start profile error
skipping to change at page 50, line 9 skipping to change at page 50, line 9
<!ATTLIST blob <!ATTLIST blob
xml:space (default|preserve) xml:space (default|preserve)
"preserve" "preserve"
status (abort|complete|continue) status (abort|complete|continue)
"continue"> "continue">
8. Reply Codes 8. Reply Codes
code meaning code meaning
==== ======= ==== =======
200 success
421 service not available 421 service not available
450 requested action not taken 450 requested action not taken
(e.g., lock already in use) (e.g., lock already in use)
451 requested action aborted 451 requested action aborted
(e.g., local error in processing) (e.g., local error in processing)
454 temporary authentication failure 454 temporary authentication failure
skipping to change at page 52, line 23 skipping to change at page 52, line 23
<http://www.w3.org/TR/1998/REC-xml-19980210>. <http://www.w3.org/TR/1998/REC-xml-19980210>.
[3] Dierks, T., Allen, C., Treese, W., Karlton, P. L., Freier, A. [3] Dierks, T., Allen, C., Treese, W., Karlton, P. L., Freier, A.
O. and P. C. Kocher, "The TLS Protocol Version 1.0", RFC 2246, O. and P. C. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
January 1999. January 1999.
[4] Myers, J.G., "Simple Authentication and Security Layer [4] Myers, J.G., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997. (SASL)", RFC 2222, October 1997.
[5] Rose, M.T., "Mapping the BEEP Framework onto TCP", [5] Rose, M.T., "Mapping the BEEP Framework onto TCP",
draft-ietf-beep-tcpmapping-04 (work in progress), October 2000. draft-ietf-beep-tcpmapping-05 (work in progress), December
2000.
[6] Postel, J., "Transmission Control Protocol", RFC 793, STD 7, [6] Postel, J., "Transmission Control Protocol", RFC 793, STD 7,
Sep 1981. Sep 1981.
[7] Crocker, D. H. and P. Overell, "Augmented BNF for Syntax [7] Crocker, D. H. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[8] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [8] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
 End of changes. 15 change blocks. 
19 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/