Subject: [Sip] Questions/Comments on privacy-04 draft

From: "George Foti (LMC)" <[email-masked]>
Date: Tue, 5 Mar 2002 09:16:46 -0500

I have some questions/comments related to the subject draft:

*	Section 4 says  "The first extension is a new general header,
Remote-Party-ID, which identifies a party and is added by the trusted
network entities"

An untrusted UAC can insert one which needs to be verified by a trusted
network entity. So the above statment seems to be  incorrect?

*	Section 5 says "If the proxy wants to ensure that the calling party
can be identified, the proxy MUST authenticate the calling party (by means
outside the scope of this document) and insert a calling party......"

Isnt the above statment true only if the UAC did not insert one, or if it
inserted one that could not be properly verified. Section 7.5 describing
proxy behavior  suggests that.
Furthermore, in that same section (7.5), it says that the proxy SHOULD
include as opposed to MUST in section 5 (I guess to account for the case
when the UAC inserts one that is verified and the proxy sets the screen to
YES)
Both sections should be consistent

*	In section 7.1 Untrusted UAC behavior - There is no mention that an
untrusted UAC can include a Remote-Party-ID header, even though the protocol
operation description section does allow for that.

*	In section 7.2 Trusted UAC behavior, it lists 2 different options,
why isnt it possible that if option 1 is followed  and a 420 response is
received, that the UAC can default to option 2, i.e  perform the necessary
actions to support requested privacy and resubmit the request to the proxy.

*	Sections 7.3 & 7.4 do not fully describe how the UAS should deal
with an incoming Request containing multiple Remote-Party-IDs. The same
comment applies to  the sections on UAC, when it comes to responses
including multiple Remote-Party-IDs.

*	Section 7.5 describing proxy behavior says that a proxy many add one
or more Remote-Party-ID headers. 
What would be the reason more than one may be included, any examples?
Thx/gf

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 05 Mar 2002 10:03:20 -0500

> network entity. So the above statment seems to be  incorrect?

The Remote-Party-Id header extension is not intended to be included by untrusted
user agents. Only trusted entities are supposed to add them, and that is what
the draft describes.

> Isnt the above statment true only if the UAC did not insert one,

No, and this is a very important point. The Remote-Party-Id is neither to be
inserted by the untrusted UA, nor is it supposed to be used by an untrusted UA
as a means of authentication - the draft is quite clear about this (see e.g. the
applicability statement)

> or if it

7.5 defines general proxy behavior and hence needs to deal with the presence or
absence of Remote-Party-Id.

> Both sections should be consistent

Section 5 says that "If the proxy wants to ensure, that the calling party can be
identified by the called party, the proxy MUST..." (note the "if"). Section 7.5
gets into more detail and says that the proxy SHOULD ensure the calling party
can be identified by including a Remote-Party-Id (if it knows the identity). I
don't see any inconsistency here.

> untrusted UAC can include a Remote-Party-ID header,

and rightfully so.

> even though the protocol

No it does not, however are rules for dealing with the case where it happened
anyway.

> actions to support requested privacy and resubmit the request to the proxy.

You can always try another option.

> including multiple Remote-Party-IDs.

They are treated similarly to the calling/called subscriber Remote-Party-Id -
it's all just identity information and no special action is taken for one party
or identity type versus another.

> What would be the reason more than one may be included, any examples?

There may be multiple types of identity information, for example "user" and
"subscriber".

-- Flemming

--
Flemming Andreasen
Cisco Systems