RFC 5364
Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists
Okay bestie, let's get into RFC 5364 🎀. The title is Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists. It's a Standards Track doc dated October 2008, written by M. Garcia-Martin and G. Camarillo at Ericsson. The title block doesn't list anything it obsoletes or updates, so it stands on its own 💅
Status of This Memo ✨
This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🦋 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.
Abstract 🌸
Okay so, in certain types of multimedia communications, a Session Initiation Protocol (SIP) request gets distributed to a group of SIP User Agents (UAs) 🫶 The sender sends one SIP request to a server, and that server passes it along to the whole group. This SIP request contains a list of Uniform Resource Identifiers (URIs) that identify the recipients, and that URI list is written as a resource list XML document.
This spec adds an XML extension to the resource list format so the sender can give each recipient a copy control level, similar to the copy control levels in existing email systems. It's giving email energy, bestie 💌
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. Extension to the Resource List Data Format . . . . . . . . . . 6
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Carrying URI Lists in SIP . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Disposition Type Registration . . . . . . . . . . . . . . 13
9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 13
9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 151. Introduction 💖
[RFC5363] [RFC5363] is the one that lays out a generic framework for carrying Uniform Resource Identifier (URI) lists in SIP [RFC3261] messages. Basically it gives all the URI-list services a shared base to build on 🧚 Two examples are conferences started with INVITE requests [RFC5366] and Multiple-recipient MESSAGE requests [RFC5365].
Every URI-list service has a SIP request holding a bunch of resources, usually written as an XML resource list [RFC4826]. These SIP requests can show up in two places: in the requests the URI-list server receives, where they list the intended recipients, or in each request the URI-list server sends out to recipients, where they list the recipients of that same SIP request 👑
Now, the XML resource list [RFC4826] is powerful, no cap, but it's missing something important. We need a copy control attribute that tells whether a resource gets the SIP request as a primary recipient, a carbon copy, or a blind carbon copy. It's just like email, where the sender can tag each recipient as "to", "cc", or "bcc" 📧
So this document fixes that by extending the XML resource list [RFC4826] so the sender can attach a copy control attribute to each recipient, labelling them "to", "cc", or "bcc". That tells the recipient whether they're getting the primary copy, a carbon copy, or a blind carbon copy. There's also a bonus: the sender can mark one or more resources in the URI list as anonymized, so some recipients' URIs don't get shown to the other recipients. Those URIs get swapped out for anonymous URIs 🙈 Main character energy for privacy.
The rest of the doc is laid out like this: Section 2 covers the terminology we use everywhere. Section 3 gives an overview of how it works. Section 4 formally defines the extension to URI lists. Section 5 has the XML schema definition. Section 6 shows examples of URI lists using the extensions from this doc. Section 7 talks about what it means to carry URI lists in SIP messages 🦋
2. Terminology 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. Those are the exact vibes we're working with, so keep an eye out 👀
Here's the vocab, periodt:
- URI-list service: a SIP application service that receives a SIP request containing a URI list and sends a similar SIP request to each URI in the list.
- Intended recipient: the intended final recipient of the request that the URI-list service generates.
- Copy control: an attribute the sender assigns to a URI in an XML resource list. It tells the recipient whether they're getting a primary, carbon, or blind carbon copy of the SIP request 💅
- Recipient list or recipient XML resource list: an XML resource list with the list of intended recipients. The sender sets this list in the SIP request they send to the URI-list server.
- Recipient-history list or recipient-history XML resource list: an XML resource list with the visible list of recipients (so, the ones that aren't anonymous and aren't bcc) ✨ The URI-list server builds this from the recipient list and includes it in each SIP request it sends to each recipient.
3. Overview of Operation ✨
okay so let's look at Figure 1 first bestie 🧚 it shows the big picture. A SIP UAC issuer sends a SIP request (F1) to a URI-list server that has a recipient list. The URI-list server then generates a SIP request to each recipient, depending on the specific SIP method. Every one of those requests carries a recipient-history list that shows the visible list of recipients. 💖
+--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | URI-list| |intended| |intended| |intended|
| issuer | | server | | recip. | | recip. | | recip. |
| | | | | 1 | | 2 | | 3 |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1 SIP request | | | |
| (recipt. list) | | | |
| ---------------->| | | |
| F2 2xx response | | | |
|<---------------- | F3 SIP request | | |
| | (recp-hist.list)| | |
| | --------------->| | |
| | F4 SIP request | | |
| | (recp-hist.list)| | |
| | -------------------------->| |
| | F5 SIP request | | |
| | (recp-hist.list)| | |
| | ------------------------------------->|
| | F6 200 OK | | |
| |<--------------- | | |
| | F7 200 OK | | |
| |<-------------------------- | |
| | F8 200 OK | | |
| |<------------------------------------- |
| | | | |
| | | | |
| | | | |
Figure 1: Example of operationThe URI-list mechanism lets a sender target multiple recipients for a SIP request by putting a recipient XML resource list [RFC4826] in the body of the request. 🎀 That list holds the target URIs of the SIP request. (The actual procedures are method specific and outside the scope of this document, so don't come for me about it 💅.) Each target URI can also get a copy control attribute that shows what copy level the recipient is getting the request at. The sender does this by qualifying each URI with a 'copyControl' attribute. The available values are "to", "cc", and "bcc", which is basically the same vibe as email 📧. We go deeper on this in Section 4. 🦋
Here's the glow-up part ✨. When the URI-list server expands the request to each recipient, it builds a recipient-history XML resource list from the recipient list the sender gave it. That recipient-history list replaces the recipient list in every SIP request the server sends out. The server copies over the targets marked "to" and "cc" and pastes them into the recipient-history list. It explicitly leaves out the URIs marked "bcc" 🙈, although it can keep a "bcc" URI if that URI matches the URI of the recipient getting the SIP request (more on that later in Section 4). So when a recipient gets the request with the recipient-history list, they can tell which other visible recipients are getting a copy, and whether those people are marked "to" or "cc". If they need to, they can reply to those visible recipients later on. main character energy, literally 👑
Now let's talk about the 'anonymize' attribute 🌸. This is a second boolean attribute, on top of 'copyControl', that we define for a URI in an XML resource list. A sender can mark a URI in a recipient XML resource list with 'anonymize' to tell the URI-list server that this URI should be swapped out for an anonymous URI in the recipient-history XML resource list. The upside is that recipients get to know how many additional visible recipients there are, even though those URIs never get disclosed 🫶.
Sometimes a sender marks several URIs with 'anonymize'. In that case, the URI-list server can group the anonymized URIs into a single anonymous URI within its copy control level, and give a count of how many anonymized URIs there were. To support this, we define a new 'count' attribute for a URI in the recipient-history XML resource list. The 'count' attribute is expected to be used only with anonymous URIs. Syntactically though, it's possible to add a 'count' attribute to any URI in any XML resource list. 🧚
You might think 'anonymize' is the same thing as the "bcc" value of 'copyControl', and honestly I thought that too at first 🙃. But they're different. If the sender qualifies a URI with a 'copyControl' attribute of "bcc" in the recipient XML resource list, the URI-list server will usually remove that URI from the recipient-history XML resource list. The exception is when the server decides to keep a "bcc" marked URI because that URI is itself the recipient of the SIP request. Recipients won't notice that any extra "bcc" URIs got the request at all 🤫. With 'anonymize', though, the URI-list server replaces the URI with an anonymous one in the recipient-history list. So recipients will notice that one or more additional recipients got the same request, but their URIs still aren't disclosed. 💜
4. Extension to the Resource List Data Format ✨
okay so this is where the magic happens 🦋 This document extends the XML resource list format from [RFC4826] so a sender can say how each recipient gets copied. We add a new copyControl attribute to the <entry> element, and it works kinda like the to, cc, and bcc fields in email [RFC2822] 💌 The values are "to", "cc", and "bcc". A "to" value means the resource is a primary recipient of the SIP request. A "cc" value means the resource gets a carbon copy. A "bcc" value means the resource gets a blind carbon copy, so that URI isn't disclosed to the other recipients of the SIP request 🙈 The default is "bcc", so the absence of a copyControl attribute MUST be treated as if the copyControl was set to "bcc" 💀
When a URI-list server builds a recipient-history list, it uses the "bcc" copyControl attributes to route SIP requests 🚀 Those "bcc" URIs are also handled kinda like email systems [RFC2822] handle them, because there are two ways to treat them. URI-list servers MUST treat these "bcc" marked URIs in either of the following two ways:
- URI-list servers MUST remove all URIs marked with a
"bcc"copy control in recipient-history lists. This lets the server send the same recipient-history list to each recipient of the SIP request 🍓 The recipients tagged with"bcc"are not explicitly told about it. - URI-list servers MUST preserve, with a
"bcc"copy control in the recipient-history list, the URI that identifies the recipient (if any), and MUST remove the remaining URIs marked with a"bcc"copy control. So each recipient gets a different recipient-history list 🧚 The recipients marked with a"bcc"copy control are explicitly told about it.
Implementations that are able to receive recipient-history lists must pay attention to the contents of the list. If the recipient's URI is not included in the recipient-history list, or if it is included but tagged with a "bcc" copy control, then implementations SHOULD prevent the user from replying to all the recipients of the SIP request 🙅♀️ This lets the non-blind recipients notice that blind recipients exist on the SIP request.
A new anonymize attribute can be included in an <entry> element of the resource list document format [RFC4826]. If it's set to a "true" value, it tells the URI-list server not to disclose the URI itself in a URI list sent to the recipient. Instead, the URI gets anonymized (made bogus in the recipient-history XML resource list) 🫥 URI-list servers can use URIs tagged with the anonymize attribute for routing SIP requests, but they MUST convert them to the SIP URI sip:anonymous@anonymous.invalid in recipient-history lists. The default value of the anonymize attribute is "false" 🌸
Sometimes the URI-list server finds the same URI entry duplicated in a resource list, and the duplicates might be tagged with the same or different copyControl values. There are no reasonable usages that justify duplicated URIs in resource lists, so this is considered an error 😭 URI-list servers should not send duplicated copies of the same SIP request to the same intended recipient. If the URI-list server finds the same URI entry duplicated in a resource list, it should send at most a single copy of the request to that intended recipient. For each set of duplicated URI entries, the URI-list server MUST select the highest precedence value of the copyControl attribute for the same intended recipient. The order of precedence for the copyControl values is "to", then "cc", then "bcc". Once the URI-list server has selected a copyControl value for an intended recipient, it can keep processing the request 👑
Processing URIs tagged with a copyControl set to "bcc" has higher precedence than the anonymize attribute. So if a URI's copyControl is "bcc", the URI-list server MUST remove that URI from the recipient-history list, and the anonymize attribute is ignored 🙈 That means the anonymize attribute is only useful for URIs tagged with a copyControl of "to" or "cc" ✨
A new count attribute can also be included in an <entry> element of the resource list document format [RFC4826]. It gives the number of equal URIs 🔢 Recipient lists created by UACs typically won't have equal (or duplicate) URI entries, so they aren't expected to contain URIs tagged with count attributes. Recipient-history lists, though, can contain duplicated anonymized URIs, so recipient-history lists are expected to contain count attributes. The default value of the count attribute is "1" 🎀
The copyControl, anonymize, and count attributes SHOULD be included as modifiers of any of the child elements included in the <list> element of a resource list (for example, an attribute of the <entry> or <external> elements) 🧸
Section 5 describes the format of the copyControl, anonymize, and count attributes. Implementations according to this specification MUST support this XML schema 💖
Implementations that receive recipient-history lists must pay attention to the contents of the list. If the recipient's URI is not included in the recipient-history list, or if it is included but tagged with a "bcc" copy control, then they SHOULD prevent the user from replying to all the recipients of the SIP request 🫶 This lets the non-blind recipients notice the existence of blind recipients in the original SIP request 👀
5. XML Schema 💅
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:copycontrol"
xmlns="urn:ietf:params:xml:ns:copycontrol"
xmlns:rls="urn:ietf:params:xml:ns:resource-lists"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation xml:lang="en">
Adds the copyControl, anonymize, and count attributes
to URIs included in a resource list.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:resource-lists"
schemaLocation="urn:ietf:params:xml:schema:resource-lists"/>
<xs:attribute name="copyControl">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="to"/>
<xs:enumeration value="cc"/>
<xs:enumeration value="bcc"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="anonymize" type="xs:boolean" default="false"/>
<xs:attribute name="count" type="xs:nonNegativeInteger"
default="1"/>
</xs:schema>Figure 2: XML schema of the extension to the resource list format
6. Examples 🍰
This section shows two examples of URI lists that can be included in SIP requests 🎂 The first example, in Figure 3, shows a recipient list that the UAC sends to the URI-list server. This corresponds to a list that will be included in flow F2 in Figure 1. The recipient list is a flat list following the resource list data format specified in RFC 4826 [RFC4826]. Each resource indicates its copy control with a copyControl attribute. Some of the resources are also marked with the anonymize attribute, which tells the URI-list service not to disclose their URIs in a recipient-history list 🕵️♀️ The last two <entry> elements are marked with a copyControl attribute of "bcc", which tells the URI-list server to remove these URIs from the recipient-history list 🫣
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:randy@example.net" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:eddy@example.com" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:carol@example.net" cp:copyControl="cc"
cp:anonymize="true"/>
<entry uri="sip:ted@example.net" cp:copyControl="bcc" />
<entry uri="sip:andy@example.com" cp:copyControl="bcc" />
</list>
</resource-lists>Figure 3: Recipient list sent from the UAC to the URI-list server
When the URI-list server gets the SIP request with the recipient list from Figure 3, it creates a SIP request to each of the URIs in the recipient list. So in our example, that's 7 SIP requests 📨 The URI-list server processes the recipient list and builds a recipient-history list that goes into each outgoing SIP request. Here's how it works 🧩 The URI-list server creates a new recipient-history list based on the recipient list, but with changes. First, it copies all the URIs (<entry> elements) marked with the "to" or "cc" copyControl attributes that don't contain an anonymize attribute (or where the anonymize attribute is set to "false"). Then, all the URIs marked with a copyControl attribute set to "to" and an anonymize attribute set to "true" are replaced with the SIP anonymous URI "sip:anonymous@anonymous.invalid". In this entry, the URI-list server also adds the original value of the copyControl attribute ("to" in our example), and it adds a count attribute containing the number of anonymous entries in this group ("2" in our example). Then the URI-list server does the same thing to the URIs tagged with a copyControl attribute set to "cc" and an anonymize attribute set to "true", adding a count attribute containing the number of anonymous attributes in this group ("1" in the example) 🌷 Last, the URI-list server removes all URIs marked with the "bcc" copyControl attribute. The resulting recipient-history list is shown in Figure 4 🦋
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to"
cp:count="2"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
cp:count="1"/>
</list>
</resource-lists>Figure 4: Recipient-history list sent from the URI-list server to each recipient
7. Carrying URI Lists in SIP ✨
okay so a SIP UAC (User Agent Client) that's putting together a SIP request can attach a URI list using the extensions in this doc to show who the intended recipients are 💌 🎀 To do that, the UAC follows RFC 5363 [RFC5363] and adds a Content-Disposition [RFC2183] header field set to recipient-list. Usually UACs send these recipient-list bodies over to URI-list services (that's flow F1 in Figure 1) 🦋 A body with the recipient-list Content-Disposition type holds a URI list of everyone the SIP request is meant for, which this doc calls a recipient list. The <entry> element in that URI list MAY also include copyControl and anonymize attributes, as described in Section 4 💅
Now, the fun part! To let recipients know who else got a copy of the SIP request, we made up a brand new mail disposition type for the Content-Disposition [RFC2183] header field of a SIP request 👀 Its value is recipient-list-history, and it says which recipients the SIP request was actually sent to. This doc calls that a recipient-history list. A body with the recipient-list-history Content-Disposition type holds a URI list of the visible recipients (anonymized ones included) of the SIP request. The <entry> element in that URI list MAY also include copyControl and count attributes, as described in Section 4 🌸
Here's the tea ☕ If a SIP request has a recipient-history list and the intended recipient doesn't support this spec, the request should not fail. To make sure the SIP requests with recipient-list-history bodies actually get delivered, User Agents (like URI-list servers) that build SIP requests with the Content-Disposition header field set to recipient-list-history SHOULD add a "handling" parameter [RFC3204] set to "optional" 🫶 Otherwise the SIP request could fail and never reach the intended recipient 😭
Also, "Message Body Handling in SIP" [SIP_BODY] says support for multipart bodies is mandatory, but legacy recipients may not support them 🙈 So if the request the relay sends to a recipient needs another body too (say, a MESSAGE request carrying a message in its body), the relay can't use this extension. The recipient wouldn't be able to process a multipart body holding both the original body and the recipient-list-history body. Not ideal, not me 💀
8. Security Considerations 🔐
RFC 5363 [RFC5363] covers the issues tied to SIP URI-list services, and this is serious business bestie 🚨 Implementations of this specification MUST follow the security-related rules in RFC 5363 [RFC5363]. Those rules include opt-in lists and mandatory authentication and authorization of clients.
User Agent Clients SHOULD NOT hand SIP requests containing URI-list services to unauthenticated and untrusted parties 🙅♀️ This helps avoid man-in-the-middle attacks, and stops people from grabbing URI lists to run spam attacks. Absolutely no vibes for that 💀
URI lists can contain private information, like SIP URIs, so it's not desirable for third parties to know them 😤 Eavesdroppers can watch URI lists inside SIP requests unless the SIP message goes over a secured channel. You can use any of the available SIP mechanisms for that, like Transport Layer Security (TLS) [RFC4346], or the URI-list body itself can be encrypted with, e.g., S/MIME [RFC3851]. So it is RECOMMENDED that URI-list bodies are encrypted with S/MIME [RFC3851], or that the SIP request is encrypted with TLS [RFC4346] or any other suitable encryption mechanism 🔒
Note that this URI list is NOT a list of the actual participants in the session 👀 It only shows the URIs that were invited and that might accept the request. It doesn't prove those parties exist, that they can be reached at the given URI, or that they accepted the invitation. Don't make any billing inferences from this info 💸 It's also open to spoofing, since someone can load the list with falsified content.
Issuers of SIP requests use the "bcc" copy control attribute from Section 4 to send requests to recipients without revealing the URIs of one or more of the other recipients 🕵️♀️ Mishandling this "bcc" copy control has consequences for confidential information. It could even lead to security problems, because someone could find out a particular URI exists at all. For example, if you use the first method from Section 4 (where the "bcc" tagged URIs get removed from the recipient-history list), blind recipients have no explicit sign that they got a blind copy. They can only tell from the fact that their URI isn't in the recipient-history list. Because of that, one of the blind URIs could reply to all of the shown recipients and accidentally reveal that the message went to the blind recipient 😱
When the second method from Section 4 is used, the blind recipient's address shows up in the recipient-history list of a separate copy of the list. If the "bcc" tagged URI that gets sent contains all of the "bcc" tagged URIs, then every "bcc" recipient will see all of the other "bcc" recipients 🙈 Even if each "bcc" recipient gets a separate message with only their own URI, implementations still need to be careful when processing replies to the message as per Section 4, so they don't accidentally reveal the blind recipient to the other recipients. Protect your besties' privacy, always 🫶
9. IANA Considerations 📋
IANA has made registrations under the following subsections: a new disposition type, a new XML namespace, and a new XML schema ✨
9.1. Disposition Type Registration
Section 7 defines a new recipient-list-history value for the Mail Content Disposition Values registry 💜 This value has been registered in the IANA registry of Mail Content Disposition Values with the following registration data:
+------------------------+------------------------------+-----------+
| Name | Description | Reference |
+------------------------+------------------------------+-----------+
| recipient-list-history | the body contains a list of | [RFC5364] |
| | URIs that indicates the | |
| | recipients of the request | |
+------------------------+------------------------------+-----------+
Table 1: Registration of the 'recipient-list-history' Mail Content
Disposition Value9.2. XML Namespace Registration
This section registers a new XML namespace in the IANA XML registry, following the guidelines in RFC 3688 [RFC3688] 🎀
URI: The URI for this namespace is urn:ietf:params:xml:ns:copycontrol
Registrant Contact: IETF SIPPING working group (sipping@ietf.org), Miguel Garcia-Martin (miguel.a.garcia@ericsson.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Copy Control Namespace</title>
</head>
<body>
<h1>Namespace for the Copy Control Attribute Extension
in Resource Lists</h1>
<h2>urn:ietf:params:xml:ns:copycontrol</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5364.txt">
RFC5364</a>.</p>
</body>
</html>
END9.3. XML Schema Registration
This section registers a new XML schema in the IANA XML registry, following the procedures in RFC 3688 [RFC3688] 🧚
URI: urn:ietf:params:xml:schema:copycontrol
Registrant Contact: IETF SIPPING working group (sipping@ietf.org), Miguel Garcia-Martin (miguel.a.garcia@ericsson.com).
The XML for this schema can be found as the sole content of Section 5 📄
10. Acknowledgments 🌷
Big thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, Atsushi Sato, Brian Rosen, Mary Barnes, James Polk, Brian E. Carpenter, and Chris Newman for reviewing this document and giving super helpful comments 🫶💖
11. References 📚
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997.
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
F., Watson, M., and M. Zonoun, "MIME media types for ISUP
and QSIG Objects", RFC 3204, December 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats
for Representing Resource Lists", RFC 4826, May 2007.
[RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) URI-
List Services", RFC 5363, October 2008.11.2. Informative References
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC5366] Camarillo, G. and A. Johnston, "Conference Establishment
Using Request-Contained Lists in the Session Initiation
Protocol (SIP)", RFC 5366, October 2008.
[RFC5365] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
MESSAGE Requests in the Session Initiation Protocol
(SIP)", RFC 5365, October 2008.
[SIP_BODY] Camarillo, G., "Message Body Handling in the Session
Initiation Protocol (SIP)", Work in Progress,
August 2008.Authors' Addresses 📮
Miguel A. Garcia-Martin
Ericsson
Via de los Poblados 13
Madrid 28033
Spain
EMail: miguel.a.garcia@ericsson.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.comFull Copyright Statement ⚖️
Lowkey boring, but the legal bits matter, so here's the full thing word for word 🙏
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.Intellectual Property ✨
Okay bestie, time for the legal-ish bit 💅. The IETF takes no position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope. It also doesn't say whether a license under those rights is or isn't available, and it hasn't done any independent digging to find such rights 🙈. If you want the rules on rights in RFC documents, check out BCP 78 and BCP 79 📚.
Copies of IPR disclosures sent to the IETF Secretariat are a thing, and so are any assurances of licenses that might be offered. You can find them in the IETF's online IPR repository at http://www.ietf.org/ipr. The same goes for the results of anyone trying to get a general license or permission to use those proprietary rights, whether they're an implementer or a user of this spec 🔍.
The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌. Keep those receipts, babe 🫶✨
📦 where this page comes from
- ietf: rfc5364 2008-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms