Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (25)
The 'anonymize' attribute is distinct from 'bcc' because bcc recipients are completely hidden (recipients don't know they exist), whereas anonymized URIs are replaced with a placeholder in the recipient-history list so that recipients know additional parties received the request but their identities are not disclosed. This provides transparency about the count of recipients without revealing their URIs.
The URI-list server can group multiple anonymized URIs sharing the same 'copyControl' level into a single anonymous entry with a 'count' attribute, rather than repeating 'sip:anonymous@anonymous.invalid' multiple times. This reduces list size while preserving recipient count information.
Legacy SIP recipients may not support multipart bodies. If the outgoing SIP request from the relay to the recipient already contains a body (e.g., a MESSAGE body), the relay may not be able to include the 'recipient-list-history' body because the recipient cannot process multipart, preventing use of this extension.
If a URI's 'copyControl' is set to 'bcc', the URI-list server MUST remove that URI from the recipient-history list; the 'anonymize' attribute is ignored for 'bcc'-tagged URIs. The 'anonymize' attribute is only useful for 'to' or 'cc' URIs.
Implementations according to this specification MUST support the XML schema defined in Section 5 for the 'copyControl', 'anonymize', and 'count' attributes.
Implementations MUST follow the security-related rules in RFC 5363, including opt-in lists and mandatory authentication and authorization of clients for URI-list services.
Implementations receiving recipient-history lists SHOULD prevent the user from replying to all recipients if the recipient's URI is not in the list or is tagged 'bcc', to avoid accidentally revealing blind recipients.
It is RECOMMENDED that URI-list bodies be encrypted with S/MIME or that the SIP request be encrypted with TLS or another suitable mechanism, since URI lists may contain private SIP URIs visible to eavesdroppers.
SIP requests containing recipient-history lists SHOULD include a Content-Disposition 'handling' parameter set to 'optional' so that the request does not fail if the recipient does not support this specification.
The absence of a 'copyControl' attribute MUST be treated as if the 'copyControl' was set to 'bcc'. This means unqualified entries default to blind carbon copy semantics.
URI-list servers MUST convert URIs tagged with the 'anonymize' attribute to the SIP URI 'sip:anonymous@anonymous.invalid' in recipient-history lists. Anonymized URIs may still be used for routing.
URI-list servers MUST treat 'bcc'-marked URIs in one of two ways: either remove all 'bcc' URIs from recipient-history lists (sending the same list to everyone), or preserve only the individual recipient's 'bcc' URI in their personalized recipient-history list while removing all other 'bcc' URIs.
When duplicate URI entries exist in a resource list with different 'copyControl' values, the URI-list server MUST select the highest precedence value for that recipient. Precedence order is: 'to' > 'cc' > 'bcc'.
A new Content-Disposition type 'recipient-list-history' is defined for SIP requests. A body with this disposition type contains a URI list of visible (including anonymized) recipients, allowing recipients to see who else received the request.
The 'anonymize' boolean attribute can be added to <entry> elements. When set to 'true', it instructs the URI-list server to replace the URI with 'sip:anonymous@anonymous.invalid' in the recipient-history list, while still routing to the real URI. The default value is 'false'.
The 'copyControl' attribute is added to the <entry> element of the XML resource list format. It takes values 'to' (primary recipient), 'cc' (carbon copy), or 'bcc' (blind carbon copy), analogous to email addressing. The default value when absent is 'bcc'.
The 'count' attribute on <entry> elements indicates the number of equal (aggregated) URIs it represents. It is primarily used in recipient-history lists to indicate how many anonymized URIs were collapsed into a single anonymous entry. The default value is '1'.
Two distinct XML resource list roles are defined: the 'recipient list' (sent by the UAC to the URI-list server, containing all intended recipients including bcc) and the 'recipient-history list' (created by the URI-list server, containing only visible recipients, sent to each recipient in the outgoing SIP requests).
This document registers 'recipient-list-history' in the IANA Mail Content Disposition Values registry. The value indicates a body containing a list of URIs identifying recipients of the SIP request.
This document registers the XML namespace 'urn:ietf:params:xml:ns:copycontrol' in the IANA XML registry per RFC 3688.
This document registers the XML schema 'urn:ietf:params:xml:schema:copycontrol' in the IANA XML registry per RFC 3688. The schema content is the sole content of Section 5.
Mishandling of 'bcc' copy control can reveal confidential information. Under the first method, blind recipients may accidentally reply-all and reveal themselves. Under the second method, if a single copy is sent containing all 'bcc' URIs, all blind recipients will see each other. Implementations must carefully process replies as per Section 4.
The URI list does not assert that listed parties exist, are reachable, or have accepted the invitation. No billing inferences should be made from the list. It is subject to spoofing by loading it with falsified content.
UACs SHOULD NOT hand SIP requests containing URI lists to unauthenticated and untrusted parties, to prevent man-in-the-middle attacks or acquisition of URI lists for spam. URI lists containing private SIP URIs must be protected against eavesdropping via TLS or S/MIME encryption.
The XML namespace for the copy control extension is 'urn:ietf:params:xml:ns:copycontrol'. The schema defines three attributes: 'copyControl' (string enumeration: to/cc/bcc), 'anonymize' (xs:boolean, default false), and 'count' (xs:nonNegativeInteger, default 1). These attributes extend the resource list <entry> and <external> elements.