[Sip]draft-rosenberg-sip-identity-coexistence-00.txt further comments

["Jesske, R" <R.Jesske at t-com.net>]

Dear all,
With regard to the following section I have some concerns regarding the
thought use of the P-Asserted-Identity.

4.3.  Ingress Proxy

....  If the identity
   is verified, the ingress proxy SHOULD insert a P-Asserted-ID header
   field containing the identity contained in the From header field of
   the request.  The proxy SHOULD NOT remove the Identity and Identity-
   Info header fields.  This allows for SIP networks where there are
   more than two administrative domains in a request path, and also
   allows for a UA to verify the signature on its own if it should
   desire....

This will violate the use of the From and P-Asserted-Identity header
within the 3GPP IMS, TISPAN IMS and also ITU-T NGN including the mapping
with the PSTN.

The P-Asserted-Identity is used as a public ID that is trusted. The From
header is set by the user itself and is untrusted. So that there is the
possibility to have two different identities within one INVITE.
To equalise such identities within a B2BUA at the ingress even if the
>From is also a now secure and trusted ID.

Within the NGN this two identities are used for PBX services to present
the main PBX number and a individual extension of the PBX.

Also the deletion and re-inclusion is against the rules of the RFC3325.
The destination domain is not allowed to change the identity of the
originating domain.

If such procedures will be done also charging and billing mechanisms
used between domains will be violated. because the P-Asserted-Identity
is the base identity of the origin domain on Billing and charging.

Best Regards

Roland



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip