Summary

  • RFC 5364 makes a relay generate recipient-specific histories from one expanded URI list. Missing copyControl becomes bcc; blind recipients disappear from other copies, while anonymize can retain only an anonymous placeholder and count.
  • Duplicate URIs should cause at most one outgoing request, with the surviving disclosure class chosen by to, then cc, then bcc; bcc separately outranks anonymize. Normalization and disclosure decisions therefore need their own receipts.
  • A history body is optional for compatibility and is explicitly not proof of actual participants, address existence, reachability, acceptance or billing. Transport protection preserves custody, not truth, completeness or later outcome.

Silence is a privacy instruction

Many schemas treat an omitted field as uncertainty. RFC 5364 does something more deliberate. When an entry has no copyControl attribute, the value is bcc. The server is not invited to inherit a user-interface default, expose the address because a neighbouring entry says to, or wait for a downstream client to decide.

This is operationally important because imported lists are rarely pristine. Older address books may know only URIs. A list editor may omit attributes after a failed migration. A producer may support the base resource-list schema but not the extension. Default-bcc contains the disclosure consequence of those gaps: the relay may still have an address to act on, yet it must not reveal that address to the other recipients.

The evidence record should show the distinction between an explicit bcc and the default applied to an absent field. Both result in blind-copy treatment, but they diagnose different conditions. One expresses author intent; the other records safe interpretation of incomplete input.

Store the original XML bytes and hash, schema version, parsed attribute presence, applied default, implementation version and resulting disclosure class. A final row saying copyControl=bcc is not enough to tell whether information was supplied, lost or safely defaulted.

The relay emits views, not a master list

RFC 5364 extends the resource-list machinery used by SIP URI-list services. A relay expands the submitted list and creates requests toward final recipients. It can attach a recipient-list history showing the recipients that are visible under the copy-control rules.

That history is not simply the source document with a new MIME type. It is a projection for one observer. A to or cc entry can remain visible. A bcc entry is withheld from other recipients. A blind recipient may receive a distinct copy in which its own URI is present so the client knows it should not expose itself through reply-all.

Consequently, two valid outgoing requests from the same expansion can carry different history bytes. Comparing them and finding a difference is not automatically evidence of tampering. The question is whether each difference follows the declared classification and recipient context.

An audit needs a fan-out map from the original list to every generated request. For each destination, preserve the input list hash, normalized entries, recipient identity, visible entries, withheld entries, anonymous placeholders, MIME disposition and body hash. Without that map, a relay can neither prove correct concealment nor explain why two recipients saw different groups.

The master list and the projected histories serve different authorities. The creator controls the requested operation. The relay enforces disclosure. The recipient sees only the view the relay is allowed to reveal.

Blind copy and anonymization reveal different facts

bcc and anonymize are sometimes described casually as two ways to hide an address. They do not produce the same evidence.

A blind-copy entry is omitted from the histories of other recipients. The group cannot infer that entry from the history itself. In the copy delivered to the blind recipient, the relay can preserve that recipient's own URI as a warning that the address is not public to the group.

An anonymized entry, by contrast, can remain represented by the standards-defined anonymous SIP placeholder. A count attribute can say that the placeholder stands for more than one hidden entry. Identity is suppressed, but existence and cardinality are disclosed.

Those are materially different privacy postures. “There are three undisclosed recipients” may affect a negotiation, an incident response or a person's willingness to reply even if no URI is shown. Omitting the entries entirely reveals less about group shape.

The relay must also honor precedence: bcc beats anonymize. An implementation that sees both and emits an anonymous placeholder has disclosed existence where the blind-copy instruction required omission. A UI that labels both simply “hidden” can conceal that policy error.

Record both source attributes, the precedence rule version and the rendered result. Privacy review should test identity leakage and cardinality leakage separately.

Duplicate collapse changes the surviving meaning

The same recipient URI can appear multiple times, perhaps through nested lists or different textual forms that compare equal under the URI scheme. RFC 5364 says there is no reasonable use in sending multiple requests to that same recipient. At most one should be sent.

The surviving copy-control classification is selected by precedence: to outranks cc, and cc outranks bcc. That rule prevents an accidental blind duplicate from suppressing a simultaneously explicit visible addressee. It also means duplicate elimination is not a neutral database operation.

Consider one URI appearing once as bcc and once as to. A raw deduplicator that keeps the first row can produce a different disclosure result from one that follows the RFC. A string-only deduplicator can miss equivalent URIs; an over-aggressive normalizer can merge genuinely different destinations. Sending twice creates its own privacy and operational problems.

The receipt must therefore contain the URI comparison method, normalization result, collision group, every source attribute, selected winner and outgoing-request count. It should be possible to replay why one request was generated and why its recipient appeared with a particular visibility.

RFC 5363 establishes the wider URI-list normalization and fan-out problem. RFC 5364 owns the narrower consequence here: duplicate identity can carry competing disclosure instructions, and the standard resolves that conflict before recipient histories are constructed.

The blind recipient needs protection from reply-all

Blind copy is not preserved solely by the relay. Once a request reaches a client, a reply-all action can disclose the blind recipient to everyone whose address was visible.

RFC 5364 therefore gives the receiving side a clue and a responsibility. If the recipient's own URI is absent from the history, or if it appears as blind, the user agent should prevent or constrain reply-all. The list is not merely decorative context; it can govern a dangerous interaction.

This control depends on identity matching. A client may have several aliases, forwarding addresses or authenticated identities. If it fails to recognize its own URI, it can either disable reply-all unnecessarily or expose a blind address. If it trusts an unverified history, a spoofed list can manipulate its behavior.

Capture what the client received, how it identified its own address, whether the history was parsed, the UI state presented to the user and the actual reply recipients. A server-side bcc decision is not evidence that confidentiality survived the endpoint.

Testing should include aliasing, multiple identities, missing history, malformed history, anonymous placeholders and ordinary visible recipients. The relevant outcome is not that a button existed. It is that no outgoing reply revealed a URI that the sender intended to keep blind.

Optional handling creates two successful states

The recipient-list history body should carry the recipient-list-history disposition and handling=optional. That choice permits compatibility with endpoints that can process the primary SIP request but do not understand the multipart body or the new disposition.

A request can therefore be accepted while the history is ignored. At the protocol layer, this is not necessarily failure. At the disclosure layer, the recipient did not acquire the view that a newer client would have received.

That split matters for product claims. “Delivered with history” can mean the relay attached bytes. It does not prove the endpoint retained the part, the client parsed it, the interface displayed it or reply-all policy used it. A legacy client may proceed without any of those results.

Preserve MIME construction, boundary and disposition, the optional-handling parameter, endpoint capability, parsing result, display result and any fallback. Metrics should distinguish request acceptance from history consumption.

Compatibility also changes risk. Ignoring an optional history may be preferable to rejecting an urgent request, but it removes context and can weaken blind-recipient safeguards. Operators need an explicit policy for services where that context is security-sensitive.

A history is not an attendance ledger

RFC 5364 is unusually direct about what the list cannot prove. The recipient-list history does not establish the actual participants in a session. An address may be syntactically listed yet nonexistent, unreachable, unanswered or declined. A reachable endpoint may be automated. A person may join through another identity.

The list cannot support billing by itself either. An invitation is not consumption. A generated request is not an accepted session. A displayed URI is not evidence of duration, capacity or the party responsible for charges.

The history can also be spoofed. A valid XML structure says that the bytes follow a schema, not that every address or classification is true. Treating the visible list as a signed social fact would lend the format authority it does not claim.

Keep later evidence separate: outgoing request disposition, endpoint response, authenticated join, media participation, duration, resource use and billing event. Each has its own clock and principal. Correlation can connect them; it must not collapse them.

This boundary is the core of the report. Recipient history answers “what disclosure view accompanied this request?” It does not answer “who was really there?”

Protection in transit does not certify the projection

Recipient lists can expose relationships and group structure, so confidentiality and integrity matter. RFC 5364 inherits the URI-list framework's authentication and authorization requirements and recommends protecting the list from untrusted parties. TLS and S/MIME address different portions of custody.

Strong transport protection can prove that bytes were protected between authenticated hops or for intended message recipients under the chosen mechanism. It does not prove that the creator's source list was honest, the relay expanded the correct version, the URI comparison was sound, precedence was applied correctly or the endpoint presented the history faithfully.

Nor does encryption make the history an outcome receipt. A perfectly protected anonymous count is still only a declared count. A protected visible address may still be unreachable. A protected omission may be policy-correct or a bug.

Record channel security, content protection, signer or peer identity, certificate or key context and verification result beside—not in place of—the transformation ledger. Security review must be able to ask both whether the artifact was protected and whether it was the right artifact.

Custody and semantics meet only through correlated evidence. Neither can borrow the other's conclusion.

The implementation needs a projection ledger

A practical ledger begins with immutable input: authenticated submitter, authorization policy, original XML bytes, schema and request context. The next stage records expansion, including nested-list resolution and the exact set of candidate URIs.

Normalization follows. Each comparison should cite the URI scheme's rules, preserve the original forms and create collision groups. Copy-control resolution then records explicit or default values, duplicate precedence and the relationship between bcc and anonymize.

Projection is a separate stage. For every outgoing recipient, compute a visible set, a withheld set and any anonymous placeholder with count. Hash the actual history body and bind it to the outgoing request ID.

Delivery produces further receipts: MIME accepted or ignored, history parsed or rejected, own-identity match, reply-all state, request response and later session evidence. Billing, if any, must refer to independently measured service, not the history.

This may look heavier than storing one final recipient array. The extra structure is exactly what makes privacy and incident review possible. If the relay keeps only its final projection, it cannot prove what was hidden. If it keeps only the master list, it cannot prove what each recipient saw.

The standard defines a boundary, not current adoption

RFC 5364's Proposed Standard status identifies a standards-track document from October 2008. The captured RFC Editor errata search displays no matching report. These facts describe the documentary record, not deployment.

This report does not claim that a named product implements the extension, that current SIP clients suppress reply-all correctly or that a real service uses recipient histories for billing. Such claims would need product documentation, versioned tests and operational evidence.

The adjacent RFCs provide context without transferring their theses. RFC 4826 defines the base resource-list format. RFC 5363 describes URI-list services and their general fan-out and security concerns. RFCs 5365 and 5366 describe related SIP uses. RFC 3261 supplies SIP foundations; the content-disposition and security references define the surrounding mechanisms.

The result is a precise engineering question that remains useful independent of adoption: when one list becomes several observer-specific views, can the system reconstruct which input, rule and recipient produced every disclosure?

The control test is per recipient

An aggregate test can confirm that the relay sent the expected number of requests. It cannot confirm that the right addresses appeared in each history.

Build fixtures that vary one dimension at a time: omitted copyControl; explicit to, cc and bcc; anonymize with one and several entries; combined bcc and anonymize; equivalent duplicate URIs with conflicting attributes; a blind recipient's own copy; a visible recipient's copy; and a legacy endpoint that ignores the optional body.

For every case, assert request count and exact history bytes. Then test the client: own-URI recognition, history rendering and reply-all suppression. Finally connect a simulated delivery and session layer to confirm that no code path turns history membership into participation or billing.

Red-team the boundaries. Mutate the source after authorization, reorder duplicates, remove attributes, spoof a history, substitute an anonymous count, strip the optional body and replay an old projection. The system should either reject the mismatch or produce a receipt explaining the accepted rule.

The correct final state is not “the list passed.” It is a chain in which the master list, resolved disclosure intent, observer-specific view and real-world outcome remain distinct and reviewable.