RFC 7572

Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging

📅 published June 2015, from ietf

RFC 7572: Interworking between SIP and XMPP: Instant Messaging 🎀

Okay bestie, here's the title block tea ☕

  • RFC number: 7572
  • Full title: Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging
  • Authors: P. Saint-Andre (&yet), A. Houri (IBM), J. Hildebrand (Cisco Systems, Inc.)
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: June 2015
  • Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🙈

Abstract

This document is giving bidirectional protocol mapping energy 💜. It defines how single instant messages get exchanged between SIP and XMPP, in both directions, so the two can talk to each other ✨.

Status of This Memo

Literally the official stamp 💅: this is an Internet Standards Track document. It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it went through public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more on Internet Standards, check Section 2 of RFC 5741.

For info on the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7572. 🦋

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) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

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 ✨

Okay so, to make sure instant messaging systems that follow the instant messaging / presence requirements in [RFC2779] can actually interwork, it's super important to clearly define protocol mappings between them 🫶. Within the IETF, work has gone into two instant messaging technologies:

  • Various extensions to the Session Initiation Protocol ([RFC3261]) for instant messaging, especially the MESSAGE method extension [RFC3428]. Together, SIP with these extensions is commonly called SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) 🌸.
  • The Extensible Messaging and Presence Protocol (XMPP), which is basically a formalization of the core XML streaming protocols that the Jabber open-source community came up with originally 👑. The relevant specs are [RFC6120] for the XML streaming layer and [RFC6121] for basic presence and instant messaging extensions.

One way to get these protocols to interwork is to map each one to the abstract semantics in [RFC3860]. That's the approach taken by [SIMPLE-CPIM] and [RFC3922]. This document goes a different route 💅: it directly maps semantics from one protocol to the other (SIP / SIMPLE to XMPP and back), because that's how existing systems already solve the interworking problem.

Both XMPP systems and IM-capable SIP systems let entities exchange "instant messages". An "instant message" usually means a message sent between two entities for delivery in close to real time, rather than one that gets stored and forwarded to the recipient when they ask for it 🍓. This document only specifies mappings for single messages (sometimes called "pager-mode" messaging), since they're the lowest common denominator for IM. Separate documents cover "session-mode" instant messaging, meaning one-to-one chat sessions [RFC7573] and multi-party chat sessions [GROUPCHAT]. Session-mode instant messaging supports several features that pager-mode doesn't, like a higher level of assurance about end-to-end message delivery 🔥. As with all of these documents, the architectural assumptions behind direct mappings are in [RFC7247], including mapping of addresses and error conditions.

2. Intended Audience 🧚

This document series is for software developers who already have a system built on one of these technologies (SIP, for example) and want to let that system talk to systems built on the other one (XMPP, for example) 💖. We assume readers already know the core specs for both SIP [RFC3261] and XMPP [RFC6120], the base document for this series [RFC7247], and these IM-related specs:

  • "Session Initiation Protocol (SIP) Extension for Instant Messaging" [RFC3428]
  • "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence" [RFC6121]

Note well 🙈: not every protocol-compliant message is shown (SIP 100 TRYING messages, for example), so you can focus on the essential parts of the protocol flows.

3. Terminology 📝

A bunch 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] 🫶.

4. XMPP to SIP 💌

As described in [RFC6121], a single instant message is an XML <message/> stanza of type "normal" sent over an XML stream. "normal" is the default for the 'type' attribute of the <message/> stanza, so the attribute often gets left out 🙃.

Say the XMPP user Juliet, whose Jabber Identifier (JID) is <juliet@example.com>, wants to send an instant message to Romeo. She talks to her XMPP client, and the client generates an XMPP <message/> stanza 💜. The syntax of the <message/> stanza, including required and optional elements and attributes, is defined in [RFC6121]. (For single instant messages, Section 5.1 of [RFC6121] recommends that the 'to' address be a "bare JID" of the form "localpart@domainpart".) Here's an example stanza:

Example 1: XMPP User Sends Message

<message from='juliet@example.com/yn0cl4bnw0yr3vym'
         to='romeo@example.net'>
  <body>Art thou not Romeo, and a Montague?</body>
</message>

When the XMPP server gets a message stanza like this, it has to figure out the domainpart of the 'to' address, and it does that by following the procedures in Section 5 of [RFC7247] 🔍. If the domain is a SIP domain, the XMPP server hands the message stanza off to an XMPP-to-SIP gateway or connection manager that natively talks to IM-aware SIP servers.

The XMPP-to-SIP gateway then translates 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: <sip:juliet@example.com;gr=yn0cl4bnw0yr3vym>;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?

The destination SIP server is responsible for delivering the message to the intended recipient, and the recipient is responsible for generating a response (for example, 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 [RFC3428] explains, a downstream proxy could fork a MESSAGE request, but it would only return one 200 OK to the gateway 😮.

Note: This document does not specify how the XMPP-to-SIP gateway handles the 200 OK (for example, 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. This is the big one, so take notes 📋✨:

Table 1: Message Syntax Mapping from XMPP to SIP

+-----------------------------+--------------------------+
|  XMPP Element or Attribute  |  SIP Header or Contents  |
+-----------------------------+--------------------------+
|  <body/>                    |  body of MESSAGE         |
|  <subject/>                 |  Subject                 |
|  <thread/>                  |  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 example above 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. It also includes the resourcepart of the "full JID" ("localpart@domainpart/resourcepart") as the Globally Routable User Agent URI (GRUU) portion [RFC5627] of the SIP URI 🌈.
  2. There's no SIP header field whose meaning matches the XMPP message 'type' values ("normal", "chat", "groupchat", "headline", "error"), so no general mapping is possible here 💀.

5. SIP to XMPP 💌

okay so, as [RFC3428] explains, a single instant message is a SIP MESSAGE request sent from a SIP user agent to an intended recipient. That recipient is usually referenced by an Instant Messaging (IM) URI [RFC3861] like <im:user@domain>, but they could also be referenced by a SIP or SIPS URI like <sip:user@domain> or <sips:user@domain>. 💅

Let's say SIP user Romeo, with the SIP URI <sip:romeo@example.net>, wants to slide into Juliet's DMs. He opens his SIP user agent, which generates a SIP MESSAGE request. The syntax of that request is defined in [RFC3428]. Here's what one looks like:

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] says a SIP user agent that gets an im: URI should resolve it to a sip: or sips: URI 🧚. So we're assuming the Request-URI of a request that reaches an IM-capable SIP-to-XMPP gateway will have a sip: or sips: URI in it. When the SIP server gets the MESSAGE, it needs to figure out the domain portion of the Request-URI or To header. It does that by following the procedures in Section 5 of [RFC7247]. If that domain is an XMPP domain, the SIP server hands the MESSAGE off to an associated SIP-to-XMPP gateway or connection manager, the one that actually talks natively to XMPP servers. Main character handoff 🎀

The SIP-to-XMPP gateway then takes over. It translates the request into an XMPP message stanza going from the SIP user to the XMPP user, and it sends a SIP 200 OK message back to the sender:

Example 5: SIP User Sends Message (XMPP Transformation)

<message from='romeo@example.net/dr4hcr0st3lup4c'
         to='juliet@example.com'>
  <body>Neither, fair saint, if either thee dislike.</body>
</message>

Quick note: the stanza-handling rules in [RFC6121] let the receiving XMPP server deliver a message stanza whose 'to' address is a bare JID ("localpart@domainpart") to multiple connected devices. This is kind of like the "forking" of messages in SIP. It's giving group chat across all your devices 📱✨

The mapping of SIP syntax to XMPP syntax MUST be as shown in the following table. No freestyling here, bestie 🫶

Table 2: Message Syntax Mapping from SIP to XMPP

+--------------------------+-----------------------------+
|  SIP Header or Contents  |  XMPP Element or Attribute  |
+--------------------------+-----------------------------+
|  Call-ID                 |  <thread/>                  |
|  Content-Language        |  xml:lang                   |
|  CSeq                    |  (no mapping)               |
|  From                    |  from (1)                   |
|  Subject                 |  <subject/>                 |
|  Request-URI or To       |  to                         |
|  body of MESSAGE         |  <body/>                    |
|  transaction identifier  |  id                         |
+--------------------------+-----------------------------+
  1. As we saw in the example above and as [RFC7247] describes, if the IM-capable SIP-to-XMPP gateway knows 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. It also has to include the GRUU as the resourcepart. That's the detail that makes the sender feel so seen 🥹

When it's transforming SIP pager-mode messages, an IM-capable SIP-to-XMPP gateway MUST specify no XMPP 'type' attribute. Or, equivalently, it can use a 'type' attribute whose value is "normal" [RFC6121]. Simple, clean, iconic 💖

See Section 7 of this document for how SIP message bodies with content types other than plain text get handled 🌈

6. Message Size 📏

[RFC3428] says that (outside of a media session) a MESSAGE request is not allowed to be bigger than 1300 bytes. In practice XMPP instant messages don't usually go over that size, but neither [RFC6120] nor [RFC6121] puts an upper limit on how big XMPP stanzas can be. Here's the plot twist 👀: XMPP server deployments usually do limit stanza size to help prevent denial-of-service attacks. And [RFC6120] says that if a server sets a maximum stanza size, that limit is not allowed to be less than 10,000 bytes. Because of this mismatch, an XMPP-to-SIP gateway SHOULD return a <policy-violation/> stanza error if an XMPP user tries to send an XMPP message stanza that would turn into a SIP MESSAGE bigger than 1300 bytes. Not today, bestie 🙅‍♀️

A gateway could maybe "upgrade" from page mode to session mode using the Message Session Relay Protocol (MSRP), which treats the instant message as part of a chat session as described in [RFC7573]. But that behavior is application-specific, and this document doesn't give any guidelines for how to finish such an upgrade. It's giving "that's a you problem" energy 🙈

7. Content Types 🎨

SIP requests of type "MESSAGE" are allowed to contain basically any content type. The recommended procedures for SIP-to-XMPP gateways to handle these content types are below.

An IM-aware SIP-to-XMPP gateway MUST process SIP messages that contain message bodies of type "text/plain". It MUST also encapsulate those message bodies as the XML character data of the XMPP <body/> element. Plain text is the main character, no cap 📝

An IM-aware SIP-to-XMPP gateway SHOULD process SIP messages that contain message bodies of type "text/html". If it does, the gateway MUST transform the "text/html" content into XHTML content that conforms to the XHTML-IM Integration Set specified in [XEP-0071]. Glow-up era 💅✨

An IM-aware SIP-to-XMPP gateway MAY process SIP messages that contain message bodies of types other than "text/plain" and "text/html". How it handles those content types is up to the implementation 🦋

8. Internationalization Considerations 🌍

Both XMPP and SIP support the UTF-8 encoding [RFC3629] of Unicode characters [UNICODE] inside messages. They also both let you tag the language of a particular message. In XMPP you do it with the 'xml:lang' attribute, and in SIP you do it with the Content-Language header. Gateways MUST map these language tagging mechanisms if they're present in the original message. Several examples follow, using the "XML Notation" [RFC3987] for Unicode characters outside the ASCII range. Multilingual bestie energy 🌸

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&#xC3A9;ho, m&#xC3A1; d&#xC49B;vo spanil&#xC3A1;,
nenavid&#xC3AD;&#xC5A1;-li jedno nebo druh&#xC3A9;.

Example 7: SIP User Sends Message (XMPP Transformation)

<message from='romeo@example.net'
         to='juliet@example.com'
         xml:lang='cs'>
  <body>
Nic z ob&#xC3A9;ho, m&#xC3A1; d&#xC49B;vo spanil&#xC3A1;,
nenavid&#xC3AD;&#xC5A1;-li jedno nebo druh&#xC3A9;.
  </body>
</message>

9. Security Considerations 🔐

Okay, this section is serious business, so read it carefully 🚨

Detailed security considerations are given in the following documents:

  • For instant messaging protocols in general, see [RFC2779]
  • For SIP-based instant messaging, see [RFC3428] and also [RFC3261]
  • For XMPP-based instant messaging, see [RFC6121] and also [RFC6120]
  • 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. [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 it translates between (i.e., SIP or MSRP and XMPP). Non-negotiable, periodt 🙅‍♀️💜

Adding gateways to the security model of instant messaging specified in [RFC2779] brings some new risks 💀. In particular, end-to-end security properties (especially confidentiality and integrity) between instant messaging clients that interface through a gateway can only be provided if common formats are supported. Specifying those common formats is out of scope for this document. For instant messages, it's 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]. Encrypt your tea ☕🔒

10. References 📚

10.1. Normative References

Here they are, every single one, exactly as written 🫶

[RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

[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,
              <http://www.rfc-editor.org/info/rfc3261>.

[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,
              <http://www.rfc-editor.org/info/rfc3428>.

[RFC3861]     Peterson, J., "Address Resolution for Instant Messaging
              and Presence", RFC 3861, DOI 10.17487/RFC3861, August
              2004, <http://www.rfc-editor.org/info/rfc3861>.

[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, <http://www.rfc-editor.org/info/rfc5627>.

[RFC6120]     Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
              March 2011, <http://www.rfc-editor.org/info/rfc6120>.

[RFC6121]     Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Instant Messaging and Presence",
              RFC 6121, DOI 10.17487/RFC6121, March 2011,
              <http://www.rfc-editor.org/info/rfc6121>.

[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,
              <http://www.rfc-editor.org/info/rfc7247>.

[XEP-0071]    Saint-Andre, P., "XHTML-IM", XSF XEP 0071, November
              2012.

10.2. Informative References 📚

okay bestie, these are the "for more context" sources 🧠 they're not required to get the core spec working, but they're where the good backstory lives 💅

[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",
              <https://otr.cypherpunks.ca/>.

[RFC2779]     Day, M., Aggarwal, S., Mohr, G., and J. Vincent,
              "Instant Messaging / Presence Protocol Requirements",
              RFC 2779, DOI 10.17487/RFC2779, February 2000,
              <http://www.rfc-editor.org/info/rfc2779>.

[RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629,
              November 2003,
              <http://www.rfc-editor.org/info/rfc3629>.

[RFC3860]     Peterson, J., "Common Profile for Instant Messaging
              (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004,
              <http://www.rfc-editor.org/info/rfc3860>.

[RFC3862]     Klyne, G. and D. Atkins, "Common Presence and Instant
              Messaging (CPIM): Message Format", RFC 3862,
              DOI 10.17487/RFC3862, August 2004,
              <http://www.rfc-editor.org/info/rfc3862>.

[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, <http://www.rfc-editor.org/info/rfc3922>.

[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, <http://www.rfc-editor.org/info/rfc3923>.

[RFC3987]     Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
              January 2005, <http://www.rfc-editor.org/info/rfc3987>.

[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,
              <http://www.rfc-editor.org/info/rfc7573>.

[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",
              <http://www.unicode.org/versions/latest/>.

Acknowledgements 🫶

big thank-you energy to everyone who gave 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, you're all iconic 👑

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 📮

here's where to find the people who made this happen ✨

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

the end, and it was SO worth reading 🌈💅

📦 where this page comes from