From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7572.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc7572.txt (limited to 'doc/rfc/rfc7572.txt') diff --git a/doc/rfc/rfc7572.txt b/doc/rfc/rfc7572.txt new file mode 100644 index 0000000..31835ad --- /dev/null +++ b/doc/rfc/rfc7572.txt @@ -0,0 +1,731 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Saint-Andre +Request for Comments: 7572 &yet +Category: Standards Track A. Houri +ISSN: 2070-1721 IBM + J. Hildebrand + Cisco Systems, Inc. + June 2015 + + + Interworking between the Session Initiation Protocol (SIP) and the + Extensible Messaging and Presence Protocol (XMPP): Instant Messaging + +Abstract + + This document defines a bidirectional protocol mapping for the + exchange of single instant messages between the Session Initiation + Protocol (SIP) and the Extensible Messaging and Presence Protocol + (XMPP). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7572. + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + +Saint-Andre, et al. Standards Track [Page 1] + +RFC 7572 SIP-XMPP Interworking: IM June 2015 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Intended Audience . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 6. Message Size . . . . . . . . . . . . . . . . . . . . . . . . 8 + 7. Content Types . . . . . . . . . . . . . . . . . . . . . . . . 8 + 8. Internationalization Considerations . . . . . . . . . . . . . 9 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 10.2. Informative References . . . . . . . . . . . . . . . . . 11 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 + +1. Introduction + + In order to help ensure interworking between instant messaging (IM) + systems that conform to the instant messaging / presence requirements + [RFC2779], it is important to clearly define protocol mappings + between such systems. Within the IETF, work has proceeded on two + instant messaging technologies: + + o Various extensions to the Session Initiation Protocol ([RFC3261]) + for instant messaging, in particular the MESSAGE method extension + [RFC3428]; collectively the capabilities of SIP with these + extensions are commonly called SIP for Instant Messaging and + Presence Leveraging Extensions (SIMPLE). + + o The Extensible Messaging and Presence Protocol (XMPP), which + consists of a formalization of the core XML streaming protocols + developed originally by the Jabber open-source community; the + relevant specifications are [RFC6120] for the XML streaming layer + and [RFC6121] for basic presence and instant messaging extensions. + + One approach to helping ensure interworking between these protocols + is to map each protocol to the abstract semantics described in + [RFC3860]; that is the approach taken by [SIMPLE-CPIM] and [RFC3922]. + In contrast, the approach taken in this document is to directly map + semantics from one protocol to another (i.e., from SIP / SIMPLE to + XMPP and vice versa), since that is how existing systems solve the + interworking problem. + + Both XMPP systems and IM-capable SIP systems enable entities to + exchange "instant messages". The term "instant message" usually + refers to a message sent between two entities for delivery in close + + + +Saint-Andre, et al. Standards Track [Page 2] + +RFC 7572 SIP-XMPP Interworking: IM June 2015 + + + to real time (rather than a message that is stored and forwarded to + the intended recipient upon request). This document specifies + mappings only for single messages (sometimes called "pager-mode" + messaging), since they form the lowest common denominator for IM. + Separate documents cover "session-mode" instant messaging in the form + of one-to-one chat sessions [RFC7573] and multi-party chat sessions + [GROUPCHAT]. In particular, session-mode instant messaging supports + several features that are not part of pager-mode instant messaging, + such as a higher level of assurance regarding end-to-end message + delivery. As with all of these documents, the architectural + assumptions underlying such direct mappings are provided in + [RFC7247], including mapping of addresses and error conditions. + +2. Intended Audience + + The documents in this series are intended for use by software + developers who have an existing system based on one of these + technologies (e.g., SIP) and who would like to enable communication + from that existing system to systems based on the other technology + (e.g., XMPP). We assume that readers are familiar with the core + specifications for both SIP [RFC3261] and XMPP [RFC6120], with the + base document for this series [RFC7247], and with the following + IM-related specifications: + + o "Session Initiation Protocol (SIP) Extension for Instant + Messaging" [RFC3428] + + o "Extensible Messaging and Presence Protocol (XMPP): Instant + Messaging and Presence" [RFC6121] + + Note well that not all protocol-compliant messages are shown (such as + SIP 100 TRYING messages), in order to focus the reader on the + essential aspects of the protocol flows. + +3. Terminology + + A number of terms used here are explained in [RFC3261], [RFC3428], + [RFC6120], and [RFC6121]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + + + + + + + +Saint-Andre, et al. Standards Track [Page 3] + +RFC 7572 SIP-XMPP Interworking: IM June 2015 + + +4. XMPP to SIP + + As described in [RFC6121], a single instant message is an XML + stanza of type "normal" sent over an XML stream (since + "normal" is the default for the 'type' attribute of the + stanza, the attribute is often omitted). + + When the XMPP user Juliet with a Jabber Identifier (JID) of + wants to send an instant message to Romeo, she + interacts with her XMPP client, which generates an XMPP + stanza. The syntax of the stanza, including required and + optional elements and attributes, is defined in [RFC6121] (for single + instant messages, Section 5.1 of [RFC6121] recommends that the value + of the 'to' address be a "bare JID" of the form + "localpart@domainpart"). The following is an example of such a + stanza: + + Example 1: XMPP User Sends Message + + | + | Art thou not Romeo, and a Montague? + | + + Upon receiving such a message stanza, the XMPP server needs to + determine the identity of the domainpart in the 'to' address, which + it does by following the procedures explained in Section 5 of + [RFC7247]. If the domain is a SIP domain, the XMPP server will hand + off the message stanza to an XMPP-to-SIP gateway or connection + manager that natively communicates with IM-aware SIP servers. + + The XMPP-to-SIP gateway is then responsible for translating the XMPP + message stanza into a SIP MESSAGE request from the XMPP user to the + SIP user: + + Example 2: XMPP User Sends Message (SIP Transformation) + + | MESSAGE sip:romeo@example.net SIP/2.0 + | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse + | Max-Forwards: 70 + | To: sip:romeo@example.net + | From: ;tag=12345 + | Call-ID: D9AA95FD-2BD5-46E2-AF0F-6CFAA96BDDFA + | CSeq: 1 MESSAGE + | Content-Type: text/plain + | Content-Length: 35 + | + | Art thou not Romeo, and a Montague? + + + +Saint-Andre, et al. Standards Track [Page 4] + +RFC 7572 SIP-XMPP Interworking: IM June 2015 + + + The destination SIP server is responsible for delivering the message + to the intended recipient, and the recipient is responsible for + generating a response (e.g., 200 OK). + + Example 3: SIP User Agent Indicates Receipt of Message + + | SIP/2.0 200 OK + | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse + | From: sip:juliet@example.com;tag=12345 + | To: sip:romeo@example.net;tag=vwxyz + | Call-ID: D9AA95FD-2BD5-46E2-AF0F-6CFAA96BDDFA + | CSeq: 1 MESSAGE + | Content-Length: 0 + + As described in [RFC3428], a downstream proxy could fork a MESSAGE + request, but it would return only one 200 OK to the gateway. + + Note: This document does not specify handling of the 200 OK by the + XMPP-to-SIP gateway (e.g., to enable message acknowledgements). + See [RFC7573] for a mapping of message acknowledgements in the + context of one-to-one chat sessions. + + The mapping of XMPP syntax to SIP syntax MUST be as shown in the + following table. + + Table 1: Message Syntax Mapping from XMPP to SIP + + +-----------------------------+--------------------------+ + | XMPP Element or Attribute | SIP Header or Contents | + +-----------------------------+--------------------------+ + | | body of MESSAGE | + | | Subject | + | | Call-ID | + | from | From (1) | + | id | transaction identifier | + | to | To or Request-URI | + | type | (no mapping) (2) | + | xml:lang | Content-Language | + +-----------------------------+--------------------------+ + + 1. As shown in the foregoing example and described in [RFC7247], the + XMPP-to-SIP gateway MUST map the bare JID + ("localpart@domainpart") of the XMPP sender to the SIP From + header and include the resourcepart of the "full JID" + ("localpart@domainpart/resourcepart") as the Globally Routable + User Agent URI (GRUU) portion [RFC5627] of the SIP URI. + + + + + +Saint-Andre, et al. Standards Track [Page 5] + +RFC 7572 SIP-XMPP Interworking: IM June 2015 + + + 2. Because there is no SIP header field that matches the meaning of + the XMPP message 'type' values ("normal", "chat", "groupchat", + "headline", "error"), no general mapping is possible here. + +5. SIP to XMPP + + As described in [RFC3428], a single instant message is a SIP MESSAGE + request sent from a SIP user agent to an intended recipient who is + most generally referenced by an Instant Messaging (IM) URI [RFC3861] + of the form but who might be referenced by a SIP or + SIPS URI of the form or . + + When a SIP user Romeo with a SIP URI of wants + to send an instant message to Juliet, he interacts with his SIP user + agent, which generates a SIP MESSAGE request. The syntax of the + MESSAGE request is defined in [RFC3428]. The following is an example + of such a request: + + Example 4: SIP User Sends Message + + | MESSAGE sip:juliet@example.com SIP/2.0 + | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677 + | Max-Forwards: 70 + | To: sip:juliet@example.com + | From: sip:romeo@example.net;tag=vwxyz + | Call-ID: 9E97FB43-85F4-4A00-8751-1124FD4C7B2E + | CSeq: 1 MESSAGE + | Content-Type: text/plain + | Content-Length: 44 + | + | Neither, fair saint, if either thee dislike. + + Section 5 of [RFC3428] stipulates that a SIP user agent presented + with an im: URI should resolve it to a sip: or sips: URI. Therefore, + we assume that the Request-URI of a request received by an IM-capable + SIP-to-XMPP gateway will contain a sip: or sips: URI. Upon receiving + the MESSAGE, the SIP server needs to determine the identity of the + domain portion of the Request-URI or To header, which it does by + following the procedures explained in Section 5 of [RFC7247]. If the + domain is an XMPP domain, the SIP server will hand off the MESSAGE to + an associated SIP-to-XMPP gateway or connection manager that natively + communicates with XMPP servers. + + The SIP-to-XMPP gateway is then responsible for translating the + request into an XMPP message stanza from the SIP user to the XMPP + user and returning a SIP 200 OK message to the sender: + + + + + +Saint-Andre, et al. Standards Track [Page 6] + +RFC 7572 SIP-XMPP Interworking: IM June 2015 + + + Example 5: SIP User Sends Message (XMPP Transformation) + + | + | Neither, fair saint, if either thee dislike. + | + + Note that the stanza-handling rules specified in [RFC6121] allow the + receiving XMPP server to deliver a message stanza whose 'to' address + is a bare JID ("localpart@domainpart") to multiple connected devices. + This is similar to the "forking" of messages in SIP. + + The mapping of SIP syntax to XMPP syntax MUST be as shown in the + following table. + + Table 2: Message Syntax Mapping from SIP to XMPP + + +--------------------------+-----------------------------+ + | SIP Header or Contents | XMPP Element or Attribute | + +--------------------------+-----------------------------+ + | Call-ID | | + | Content-Language | xml:lang | + | CSeq | (no mapping) | + | From | from (1) | + | Subject | | + | Request-URI or To | to | + | body of MESSAGE | | + | transaction identifier | id | + +--------------------------+-----------------------------+ + + 1. As shown in the foregoing example and described in [RFC7247], if + the IM-capable SIP-to-XMPP gateway has information about the GRUU + [RFC5627] of the particular endpoint that sent the SIP message, + then it MUST map the sender's address to a full JID + ("localpart@domainpart/resourcepart") in the 'from' attribute of + the XMPP stanza and include the GRUU as the resourcepart. + + When transforming SIP pager-mode messages, an IM-capable SIP-to-XMPP + gateway MUST specify no XMPP 'type' attribute or, equivalently, a + 'type' attribute whose value is "normal" [RFC6121]. + + See Section 7 of this document about the handling of SIP message + bodies that contain content types other than plain text. + + + + + + + + +Saint-Andre, et al. Standards Track [Page 7] + +RFC 7572 SIP-XMPP Interworking: IM June 2015 + + +6. Message Size + + [RFC3428] specifies that (outside of a media session) the size of a + MESSAGE request is not allowed to exceed 1300 bytes. Although, in + practice, XMPP instant messages do not often exceed that size, + neither [RFC6120] nor [RFC6121] sets an upper limit on the size of + XMPP stanzas. However, XMPP server deployments usually do limit the + size of stanzas in order to help prevent denial-of-service attacks, + and [RFC6120] states that if a server sets a maximum stanza size, + then the limit is not allowed to be less than 10,000 bytes. Because + of this mismatch, an XMPP-to-SIP gateway SHOULD return a stanza error if an XMPP user attempts to send an XMPP + message stanza that would result in a SIP MESSAGE greater than 1300 + bytes. Although such a gateway might decide to "upgrade" from page + mode to session mode using the Message Session Relay Protocol (MSRP) + -- thus treating the instant message as part of a chat session as + described in [RFC7573] -- such behavior is application-specific and + this document provides no guidelines for how to complete such an + upgrade. + +7. Content Types + + SIP requests of type "MESSAGE" are allowed to contain essentially any + content type. The recommended procedures for SIP-to-XMPP gateways to + use in handling these content types are as follows. + + An IM-aware SIP-to-XMPP gateway MUST process SIP messages that + contain message bodies of type "text/plain" and MUST encapsulate such + message bodies as the XML character data of the XMPP element. + + An IM-aware SIP-to-XMPP gateway SHOULD process SIP messages that + contain message bodies of type "text/html"; if so, a gateway MUST + transform the "text/html" content into XHTML content that conforms to + the XHTML-IM Integration Set specified in [XEP-0071]. + + Although an IM-aware SIP-to-XMPP gateway MAY process SIP messages + that contain message bodies of types other than "text/plain" and + "text/html", the handling of such content types is a matter of + implementation. + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 8] + +RFC 7572 SIP-XMPP Interworking: IM June 2015 + + +8. Internationalization Considerations + + Both XMPP and SIP support the UTF-8 encoding [RFC3629] of Unicode + characters [UNICODE] within messages, along with tagging of the + language for a particular message (in XMPP via the 'xml:lang' + attribute and in SIP via the Content-Language header). Gateways MUST + map these language tagging mechanisms if they are present in the + original message. Several examples follow, using the "XML Notation" + [RFC3987] for Unicode characters outside the ASCII range. + + Example 6: SIP User Sends Message + + | MESSAGE sip:juliet@example.com SIP/2.0 + | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677 + | Max-Forwards: 70 + | To: sip:juliet@example.com + | From: sip:romeo@example.net;tag=vwxyz + | Call-ID: 5A37A65D-304B-470A-B718-3F3E6770ACAF + | CSeq: 1 MESSAGE + | Content-Type: text/plain + | Content-Length: 45 + | Content-Language: cs + | + | Nic z ob쎩ho, m쎡 d쒛vo spanil쎡, + | nenavid쎭얡-li jedno nebo druh쎩. + + Example 7: SIP User Sends Message (XMPP Transformation) + + | + | + | Nic z ob쎩ho, m쎡 d쒛vo spanil쎡, + | nenavid쎭얡-li jedno nebo druh쎩. + | + | + +9. Security Considerations + + Detailed security considerations are given in the following + documents: + + o For instant messaging protocols in general, see [RFC2779] + + o For SIP-based instant messaging, see [RFC3428] and also [RFC3261] + + o For XMPP-based instant messaging, see [RFC6121] and also [RFC6120] + + + + +Saint-Andre, et al. Standards Track [Page 9] + +RFC 7572 SIP-XMPP Interworking: IM June 2015 + + + o For SIP-XMPP interworking in general, see [RFC7247] + + This document specifies methods for exchanging "pager-mode" instant + messages through a gateway that translates between SIP and XMPP, and + [RFC7573] specifies such methods for "session-mode" instant messaging + between MSRP and XMPP. Such a gateway MUST be compliant with the + minimum security requirements of the textual chat protocols for which + it translates (i.e., SIP or MSRP and XMPP). + + The addition of gateways to the security model of instant messaging + specified in [RFC2779] introduces some new risks. In particular, + end-to-end security properties (especially confidentiality and + integrity) between instant messaging clients that interface through a + gateway can be provided only if common formats are supported. + Specification of those common formats is out of scope for this + document. For instant messages, it is possible to use the methods + described in [RFC3862] and [RFC3923], but those methods are not + widely implemented. A more widely implemented, albeit + nonstandardized, method for interoperable end-to-end encryption would + be Off-the-Record Messaging [OTR]. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., + Johnston, A., Peterson, J., Sparks, R., Handley, M., + and E. Schooler, "SIP: Session Initiation Protocol", + RFC 3261, DOI 10.17487/RFC3261, June 2002, + . + + [RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., + Huitema, C., and D. Gurle, "Session Initiation Protocol + (SIP) Extension for Instant Messaging", RFC 3428, + DOI 10.17487/RFC3428, December 2002, + . + + [RFC3861] Peterson, J., "Address Resolution for Instant Messaging + and Presence", RFC 3861, DOI 10.17487/RFC3861, August + 2004, . + + + + + + +Saint-Andre, et al. Standards Track [Page 10] + +RFC 7572 SIP-XMPP Interworking: IM June 2015 + + + [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable + User Agent URIs (GRUUs) in the Session Initiation + Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, + October 2009, . + + [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence + Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, + March 2011, . + + [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence + Protocol (XMPP): Instant Messaging and Presence", + RFC 6121, DOI 10.17487/RFC6121, March 2011, + . + + [RFC7247] Saint-Andre, P., Houri, A., and J. Hildebrand, + "Interworking between the Session Initiation Protocol + (SIP) and the Extensible Messaging and Presence + Protocol (XMPP): Architecture, Addresses, and Error + Handling", RFC 7247, DOI 10.17487/RFC7247, May 2014, + . + + [XEP-0071] Saint-Andre, P., "XHTML-IM", XSF XEP 0071, November + 2012. + +10.2. Informative References + + [GROUPCHAT] Saint-Andre, P., Corretge, S., and S. Loreto, + "Interworking between the Session Initiation Protocol + (SIP) and the Extensible Messaging and Presence + Protocol (XMPP): Groupchat", Work in Progress, + draft-ietf-stox-groupchat-11, March 2015. + + [OTR] Goldberg, I., "Off-the-Record Messaging", + . + + [RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, + "Instant Messaging / Presence Protocol Requirements", + RFC 2779, DOI 10.17487/RFC2779, February 2000, + . + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, + November 2003, + . + + [RFC3860] Peterson, J., "Common Profile for Instant Messaging + (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004, + . + + + +Saint-Andre, et al. Standards Track [Page 11] + +RFC 7572 SIP-XMPP Interworking: IM June 2015 + + + [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant + Messaging (CPIM): Message Format", RFC 3862, + DOI 10.17487/RFC3862, August 2004, + . + + [RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and + Presence Protocol (XMPP) to Common Presence and Instant + Messaging (CPIM)", RFC 3922, DOI 10.17487/RFC3922, + October 2004, . + + [RFC3923] Saint-Andre, P., "End-to-End Signing and Object + Encryption for the Extensible Messaging and Presence + Protocol (XMPP)", RFC 3923, DOI 10.17487/RFC3923, + October 2004, . + + [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource + Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, + January 2005, . + + [RFC7573] Saint-Andre, P. and S. Loreto, "Interworking between + the Session Initiation Protocol (SIP) and the + Extensible Messaging and Presence Protocol (XMPP): + One-to-One Text Chat Sessions", RFC 7573, + DOI 10.17487/RFC7573, June 2015, + . + + [SIMPLE-CPIM] Campbell, B. and J. Rosenberg, "CPIM Mapping of SIMPLE + Presence and Instant Messaging", Work in Progress, + draft-ietf-simple-cpim-mapping-01, June 2002. + + [UNICODE] The Unicode Consortium, "The Unicode Standard", + . + + + + + + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 12] + +RFC 7572 SIP-XMPP Interworking: IM June 2015 + + +Acknowledgements + + The authors wish to thank the following individuals for their + feedback: Mary Barnes, Dave Cridland, Dave Crocker, Adrian Georgescu, + Christer Holmberg, Saul Ibarra Corretge, Olle Johansson, Paul + Kyzivat, Salvatore Loreto, Daniel-Constantin Mierla, and Tory Patnoe. + + Special thanks to Ben Campbell for his detailed and insightful + reviews. + + Francis Dupont reviewed the document on behalf of the General Area + Review Team. + + Spencer Dawkins, Stephen Farrell, and Barry Leiba provided helpful + input during IESG review. + + The authors gratefully acknowledge the assistance of Markus Isomaki + and Yana Stamcheva as the working group chairs and Gonzalo Camarillo + and Alissa Cooper as the sponsoring Area Directors. + + Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for + employing him during his work on earlier draft versions of this + document. + +Authors' Addresses + + Peter Saint-Andre + &yet + EMail: peter@andyet.com + URI: https://andyet.com/ + + + Avshalom Houri + IBM + Rorberg Building, Pekris 3 + Rehovot 76123 + Israel + EMail: avshalom@il.ibm.com + + + Joe Hildebrand + Cisco Systems, Inc. + 1899 Wynkoop Street, Suite 600 + Denver, CO 80202 + United States + EMail: jhildebr@cisco.com + + + + + +Saint-Andre, et al. Standards Track [Page 13] + -- cgit v1.2.3