During WGLC on draft-ietf-sipping-update-pai-08, I received a comment that if a node includes PAI in a request such as UPDATE, together with Privacy 'id', and sends the request to another node in the Trust Domain, if that other node does not comply with update-pai it might fail to handle the Privacy header field correctly. I think this is a matter for Spec(T). Alternatively, if not covered by Spec(T), care should be taken not to send PAI in such circumstances. I propose to add the following to the end of section 4.5: "When a UAC or a proxy sends a request containing a P-Asserted-Identity header field to another node in the Trust Domain, if that other node complies with RFC 3325 but not with this specification, and if the method is not one for which RFC 3325 specifies use of the P-Asserted-Identity header field, and if the request also contains a Privacy header field with value 'id', as specified in RFC 3325, the other node might not handle the Privacy header field correctly. To prevent incorrect handling of the Privacy header field with value 'id', the Spec(T) in force for the Trust Domain SHOULD require all nodes to comply with this specification. If this is not the case, a UAC or a proxy SHOULD NOT include a P-Asserted-Identity header field in a request if the method is not one for which RFC 3325 specifies use of the P-Asserted-Identity header field and if the request also contains a Privacy header field with value 'id'." Today is the last day of WGLC, so if there are no objections to the above and no further comments, I will post an 09 version with this change. John _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
