RFC 6044, "Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)", October 2010

Note: This RFC has been obsoleted by RFC 7544

Errata ID: 3564
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jayaraj Wilson
Date Reported: 2013-03-25
Rejected by: Nevil Brownlee
Date Rejected: 2014-02-12

Section 7.1 says:

Mapped into:
History-Info:
<sip: diverting_user1_address; privacy=none >; index=1,
<sip: diverting_user2_address; cause=408?privacy=history>;index=1.1,
<sip: diverting_user3_address; cause=486?privacy=none>;index=1.1.1,
<sip: last_diverting_target; cause=302>;index=1.1.1.1

It should say:

Mapped into:
History-Info:
<sip: diverting_user1_address; privacy=none >; index=1,
<sip: diverting_user2_address; cause=408?privacy=history>;index=1.1,
<sip: diverting_user3_address; cause=486?privacy=none>;index=1.1.1,
<sip: last_diverting_target; cause=302?privacy=none>;index=1.1.1.1

Notes:

Section 5 for Diversion to History Info mapping states
A last History-Info entry is created and contains:
- if a privacy parameter is present in the top-most Diversion entry,
then a Privacy header could be escaped in the History-Info header
as described above.

So if this is rule is applied then the last History Info entry must contain a privacy param corresponding to the top most Diversion and in this case it maps to none. On the other hand if this example is to be considered correct then we ought to modify section 5 to have no privacy for the last hi entry.
--VERIFIER NOTES--
In RFC 6044 section 7.1, the last History-Info line does not
correspond to the last diverting user (similar to the top-most
diversion entry), but to the last diversion TARGET. We don't have the
privacy of the last call forwarding destination - that's why there is
no privacy associated to this address.

The privacy info associated to diverting users 1, 2 and 3 are still
associated to these user addresses in the History-Info header.

Report New Errata