Subject: [Sipping] RE: comments on :draft-ietf-sipping-qsig2sip-04.txt

From: "Elwell, John" <[email-masked]>
Date: Sun, 22 Feb 2004 18:17:10 +0000

Cullen,

See in-line.

John

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 17 February 2004 16:00
> To: [email-masked]; Elwell, John
> Subject: comments on :draft-ietf-sipping-qsig2sip-04.txt
> 
> 
> 
> One major concern, Section 9.1.3 and 9.2.3 - PAI won't work 
> for this as
> described in draft-jennings-sipping-connected-00. I highly 
> recommend we talk
> about this on a phone call or in Korea and get it sorted out. 
> Suggesting a
> solution here will just make solving this problem more 
> complex. Even if you
> think that it does work, it is definitely a new semantic 
> meaning of PAI that
> is not covered in any the current documents. This would 
> require the qsig2sip
> document to be dealt with in the sip WG instead of sipping it 
> it is going to
> extend the meaning of PAI. 
[JRE]  See attached email thread, in which I received only support for the
use of PAI in a response. For the reasons given in the first email in the
thread, and also for the additional reason stated in the response from Keith
Drage, I don't believe the qsig2sip document is extending the meaning of
PAI.

> It is recognized that SIP is 
> lacking in this
> area, there have been multiple drafts proposing solutions 
> (including the
> work in draft-elwell-sip-state-update). I think it would be 
> better to get
> one of theses solutions moving and just use it here.
> 
> Few minor things:
> 
> If the GW signs a sipfrag, what should be in the SubjectAltName of the
> certificate?
[JRE] It would have to be something that identifies the gateway.

> 
> Section 9.1 (and other places) The terminology "the gw trusts 
> the next hop"
> is wrong and should be something more like "the GW is in the 
> same trust
> domain (as defined in RFC 3325) as the next hop"
[JRE] OK

> 
> Section 9.2.2 If the From is Anonymous, and there is no 
> privacy value, then
> it should be treated as if there was a privacy value of id.
[JRE] OK

> 
> NIT:
> 
> I find reference style of "as described in [10]" much harder 
> to read than "
> as described in RFC 3261 [10]"
[JRE] I don't mind. Is there a documented preference? RFCs such as 3325 and
3261 are certainly not consistent in this respect.

> 
> Cullen
> 
> 
> On 1/20/04 7:05 AM, "[email-masked]" 
> <[email-masked]>
> wrote:
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Session Initiation 
> Proposal Investigation
> > Working Group of the IETF.
> > 
> > Title        : Interworking between SIP and QSIG
> > Author(s)    : J. Elwell
> > Filename    : draft-ietf-sipping-qsig2sip-04.txt
> > Pages        : 61
> > Date        : 2004-1-19
> > 
> > This document specifies interworking between the Session Initiation
> >  Protocol (SIP) and QSIG within corporate telecommunication networks
> >  (also known as enterprise networks). SIP is an Internet 
> application-
> >  layer control (signalling) protocol for creating, modifying, and
> >  terminating sessions with one or more participants. These sessions
> >  include, in particular, telephone calls. QSIG is a signalling
> >  protocol for creating, modifying and terminating circuit-switched
> >  calls, in particular telephone calls, within Private Integrated
> >  Services Networks (PISNs). QSIG is specified in a number of ECMA
> >  Standards and published also as ISO/IEC standards.
> > 
> > A URL for this Internet-Draft is:
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-04.txt
> > 
> > To remove yourself from the IETF Announcement list, send a 
> message to
> > ietf-announce-request with the word unsubscribe in the body 
> of the message.
> > 
> > Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > "get draft-ietf-sipping-qsig2sip-04.txt".
> > 
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > [email-masked].
> > In the body type:
> > "FILE /internet-drafts/draft-ietf-sipping-qsig2sip-04.txt".
> > 
> > NOTE:    The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility.  To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command.  To decode the response(s), you will need "munpack" or
> > a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been split
> > up into multiple messages), so check your local documentation on
> > how to manipulate these messages.
> > 
> > 
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> > 
> > Content-Type: text/plain
> > Content-ID:    <[email-masked]>
> > 
> > ENCODING mime
> > FILE /internet-drafts/draft-ietf-sipping-qsig2sip-04.txt
> > 
> 

Subject: RE: [Sip] Use of P-Asserted-Identity in a response
From: Mark Watson <[email-masked]>
To: "'Elwell, John'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Mon, 19 Jan 2004 12:59:31 +0000

John, 

It was certainly the intention when 3324/3325 were written that PAI could
appear in responses. The term message was used deliberately. I am not sure
where opinions to the contrary have come from - has someone claimed that a
'response' is not a 'message' ?

...Mark 

-----Original Message----- 
From: Elwell, John [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: 02 January 2004 16:11 
To: [email-masked] 
Subject: [Sip] Use of P-Asserted-Identity in a response 

There seem to be some differences of opinion concerning the use of
P-Asserted-Identity (PAI) in a response. In particular, this is delaying the
progress of draft-ietf-sipping-qsig2sip, which makes use of PAI in a 200 OK
to convey the connected party identity received from the QSIG network. The
same situation is likely to be encountered when interworking with other
legacy signalling systems.

It is my opinion that PAI can be used in a 200 OK to assert the identity of
the connect party. Moreover, it can be inserted by a gateway UAS and, unless
subject to privacy, can be passed on even to untrusted entities including
the UAC.

My evidence for assuming this is as follows: 

1. RFC 3325: In section 5, 2nd paragraph it states: 
"If the proxy receives a message (request or response) from a node that it
trusts, it can use the information in the P-Asserted-Identity header field,
if any, as if it had authenticated the user itself." There is nowhere that
forbids the use of P-Asserted-ID in a response, although there are places in
the RFC that mention procedures for a request without mentioning a response.
In many places it talks about "message", which, according to the text above,
means request or response.

2. RFC 3324 clause 5 clearly states that PAI in INVITE identifies the
calling user, PAI in a 180 response the ringing user and PAI in 200 OK the
user who answered the call. RFC 3325 is supposed to meet the requirement of
RFC3324.

I have seen a number of arguments against the use of PAI in a response: 

a) It has been suggested that a PAI in a response represents the identity of
the entity that issued the request. This does not hold water. It clearly
would be in contradiction to clause 5 of RFC3324 and there is nowhere in
RFC3324 or RFC3325 that suggests echoing in a response the PAI in the
request.

b)It has been suggested that there would need to be corresponding privacy
requirements for identity information in a response. However, RFC 3323 does
indeed address privacy in responses. See last paragraph of section 3: "It
may be desirable to restrict identity information on both requests and
responses.  Initially, it might seem unusual to suggest that a response has
privacy concerns - presumably, the originator of the request knows who they
were attempting to contact, so the identity of the respondent can hardly be
confidential.  However, some personal information in responses (such as the
contact address at which the respondent is currently registered) is subject
to privacy concerns and can be addressed by these mechanisms." Also see
section 4.2, which states: "...this document defines a new SIP header,
Privacy, that can be used to specify privacy handling for requests and
responses."

c)It has been argued that using PAI in a response may cause an existing
implementation to do the wrong thing with respect to privacy, e.g., if
privacy is required by the caller, a proxy may apply this to the connected
user's identity in the response as well. I don't think this is a likely
scenario in view of RFC 3323's coverage of privacy in requests and
responses.

d)Also it has been suggested that an existing UAS may not take care to
request privacy in a response, not realising that a proxy might add a PAI.
Again, since RFC 3323 covers privacy in both requests and responses, any UA
implementation that supports privacy in requests should also support privacy
in responses.

e) It has been pointed out that a proxy cannot reject a response if the PAI
is wrong. I don't believe this matters - it should be sufficient for the
proxy just to strip out a PAI that is wrong.

In conclusion, I see evidence that PAI can be used in a response to assert
the ID of the connected party and no solid evidence to the contrary.

John Elwell ([email-masked]) 

_______________________________________________ 
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
<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

Subject: RE: [Sip] Use of P-Asserted-Identity in a response
From: "Drage, Keith (Keith)" <[email-masked]>
To: "Elwell, John" <[email-masked]>, [email-masked]
Date: Sun, 04 Jan 2004 00:57:31 +0000

RFC 3325 section 9.1 and section 9.2 both extend table 2 of RFC 3261 with
the new header.

Both entires leave the "where" column empty.

The key to RFC 3261 table 2 states:

      An empty entry in the "where" column indicates that the header
           field may be present in all requests and responses.

I would therefore conclude from the existing specification that both headers
may appear in any response to BYE, INV, OPT, SUB, NOT, REF, i.e. those
methods that either create a dialog, or are used outside a dialog.

As MESSAGE appeared after RFC 3325 I would also assume that it is allowed in
the MESSAGE method, in both requests and all responses.

Note that these tables do not restrict it to 18x and 2xx responses, although
for ISDN mapping purposes those responses are the useful ones. It is
perfectly valid in 3xx, 4xx and 5xx responses.

Any assertion of identity in responses (and its value) is of course
dependent on the specification of privacy by the UAS and on the requirements
of the first proxy in the trust domain.

This usage corresponds to what has been specified in 3GPP TS 24.229 and I
believe in ITU-T Q.1912.5.

regards

Keith 

> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]]
> Sent: 02 January 2004 16:11
> To: [email-masked]
> Subject: [Sip] Use of P-Asserted-Identity in a response
> 
> 
> There seem to be some differences of opinion concerning the use of
> P-Asserted-Identity (PAI) in a response. In particular, this 
> is delaying the
> progress of draft-ietf-sipping-qsig2sip, which makes use of 
> PAI in a 200 OK
> to convey the connected party identity received from the QSIG 
> network. The
> same situation is likely to be encountered when interworking 
> with other
> legacy signalling systems.
> 
> It is my opinion that PAI can be used in a 200 OK to assert 
> the identity of
> the connect party. Moreover, it can be inserted by a gateway 
> UAS and, unless
> subject to privacy, can be passed on even to untrusted 
> entities including
> the UAC.
> 
> My evidence for assuming this is as follows:
> 
> 1. RFC 3325: In section 5, 2nd paragraph it states:
> "If the proxy receives a message (request or response) from a 
> node that it
> trusts, it can use the information in the P-Asserted-Identity 
> header field,
> if any, as if it had authenticated the user itself."
> There is nowhere that forbids the use of P-Asserted-ID in a response,
> although there are places in the RFC that mention procedures 
> for a request
> without mentioning a response. In many places it talks about 
> "message",
> which, according to the text above, means request or response.
> 
> 2. RFC 3324 clause 5 clearly states that PAI in INVITE identifies the
> calling user, PAI in a 180 response the ringing user and PAI 
> in 200 OK the
> user who answered the call. RFC 3325 is supposed to meet the 
> requirement of
> RFC3324.
> 
> I have seen a number of arguments against the use of PAI in a 
> response:
> 
> a) It has been suggested that a PAI in a response represents 
> the identity of
> the entity that issued the request. This does not hold water. 
> It clearly
> would be in contradiction to clause 5 of RFC3324 and there is 
> nowhere in
> RFC3324 or RFC3325 that suggests echoing in a response the PAI in the
> request.
> 
> b)It has been suggested that there would need to be 
> corresponding privacy
> requirements for identity information in a response. However, 
> RFC 3323 does
> indeed address privacy in responses. See last paragraph of section 3:
> "It may be desirable to restrict identity information on both 
> requests and
> responses.  Initially, it might seem unusual to suggest that 
> a response has
> privacy concerns - presumably, the originator of the request 
> knows who they
> were attempting to contact, so the identity of the respondent 
> can hardly be
> confidential.  However, some personal information in 
> responses (such as the
> contact address at which the respondent is currently 
> registered) is subject
> to privacy concerns and can be addressed by these mechanisms."
> Also see section 4.2, which states:
> "...this document defines a new SIP header, Privacy, that can 
> be used to
> specify privacy handling for requests and responses."
> 
> c)It has been argued that using PAI in a response may cause 
> an existing
> implementation to do the wrong thing with respect to privacy, e.g., if
> privacy is required by the caller, a proxy may apply this to 
> the connected
> user's identity in the response as well. I don't think this 
> is a likely
> scenario in view of RFC 3323's coverage of privacy in requests and
> responses.
> 
> d)Also it has been suggested that an existing UAS may not take care to
> request privacy in a response, not realising that a proxy 
> might add a PAI.
> Again, since RFC 3323 covers privacy in both requests and 
> responses, any UA
> implementation that supports privacy in requests should also 
> support privacy
> in responses.
> 
> e) It has been pointed out that a proxy cannot reject a 
> response if the PAI
> is wrong. I don't believe this matters - it should be 
> sufficient for the
> proxy just to strip out a PAI that is wrong.
> 
> In conclusion, I see evidence that PAI can be used in a 
> response to assert
> the ID of the connected party and no solid evidence to the contrary.
> 
> John Elwell ([email-masked])
> 
> _______________________________________________
> 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
> 

Subject: Re: [Sip] Use of P-Asserted-Identity in a response
From: Tom Taylor <[email-masked]>
To: David Oran <[email-masked]>
Cc: "Elwell, John" <[email-masked]>, [email-masked]
Date: Sun, 04 Jan 2004 00:27:28 +0000

I would also support this usage.

David Oran wrote:

> These arguments are good ones.
> Even if they weren't good I'd still be in favor of what John proposes, 
> because it's eminently reasonable and provides desperately needed 
> functionality for which we currently have no alternative machinery.
> 
> Dave.
> 
> --On Friday, January 2, 2004 4:10 PM +0000 "Elwell, John" 
> <[email-masked]> wrote:
> 
>> There seem to be some differences of opinion concerning the use of
>> P-Asserted-Identity (PAI) in a response. In particular, this is delaying
>> the progress of draft-ietf-sipping-qsig2sip, which makes use of PAI in a
>> 200 OK to convey the connected party identity received from the QSIG
>> network. The same situation is likely to be encountered when interworking
>> with other legacy signalling systems.
>>
>> It is my opinion that PAI can be used in a 200 OK to assert the identity
>> of the connect party. Moreover, it can be inserted by a gateway UAS and,
>> unless subject to privacy, can be passed on even to untrusted entities
>> including the UAC.
>>
>> My evidence for assuming this is as follows:
>>
>> 1. RFC 3325: In section 5, 2nd paragraph it states:
>> "If the proxy receives a message (request or response) from a node 
>> that it
>> trusts, it can use the information in the P-Asserted-Identity header
>> field, if any, as if it had authenticated the user itself."
>> There is nowhere that forbids the use of P-Asserted-ID in a response,
>> although there are places in the RFC that mention procedures for a 
>> request
>> without mentioning a response. In many places it talks about "message",
>> which, according to the text above, means request or response.
>>
>> 2. RFC 3324 clause 5 clearly states that PAI in INVITE identifies the
>> calling user, PAI in a 180 response the ringing user and PAI in 200 OK 
>> the
>> user who answered the call. RFC 3325 is supposed to meet the requirement
>> of RFC3324.
>>
>> I have seen a number of arguments against the use of PAI in a response:
>>
>> a) It has been suggested that a PAI in a response represents the identity
>> of the entity that issued the request. This does not hold water. It
>> clearly would be in contradiction to clause 5 of RFC3324 and there is
>> nowhere in RFC3324 or RFC3325 that suggests echoing in a response the PAI
>> in the request.
>>
>> b)It has been suggested that there would need to be corresponding privacy
>> requirements for identity information in a response. However, RFC 3323
>> does indeed address privacy in responses. See last paragraph of 
>> section 3:
>> "It may be desirable to restrict identity information on both requests 
>> and
>> responses.  Initially, it might seem unusual to suggest that a response
>> has privacy concerns - presumably, the originator of the request knows
>> who they were attempting to contact, so the identity of the respondent
>> can hardly be confidential.  However, some personal information in
>> responses (such as the contact address at which the respondent is
>> currently registered) is subject to privacy concerns and can be addressed
>> by these mechanisms."
>> Also see section 4.2, which states:
>> "...this document defines a new SIP header, Privacy, that can be used to
>> specify privacy handling for requests and responses."
>>
>> c)It has been argued that using PAI in a response may cause an existing
>> implementation to do the wrong thing with respect to privacy, e.g., if
>> privacy is required by the caller, a proxy may apply this to the 
>> connected
>> user's identity in the response as well. I don't think this is a likely
>> scenario in view of RFC 3323's coverage of privacy in requests and
>> responses.
>>
>> d)Also it has been suggested that an existing UAS may not take care to
>> request privacy in a response, not realising that a proxy might add a 
>> PAI.
>> Again, since RFC 3323 covers privacy in both requests and responses, any
>> UA implementation that supports privacy in requests should also support
>> privacy in responses.
>>
>> e) It has been pointed out that a proxy cannot reject a response if the
>> PAI is wrong. I don't believe this matters - it should be sufficient for
>> the proxy just to strip out a PAI that is wrong.
>>
>> In conclusion, I see evidence that PAI can be used in a response to 
>> assert
>> the ID of the connected party and no solid evidence to the contrary.
>>
>> John Elwell ([email-masked])
>>
>> _______________________________________________
>> 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
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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
> 

Subject: Re: [Sip] Use of P-Asserted-Identity in a response
From: David Oran <[email-masked]>
To: "Elwell, John" <[email-masked]>, [email-masked]
Date: Sat, 03 Jan 2004 19:13:24 +0000

These arguments are good ones.
Even if they weren't good I'd still be in favor of what John proposes, 
because it's eminently reasonable and provides desperately needed 
functionality for which we currently have no alternative machinery.

Dave.

--On Friday, January 2, 2004 4:10 PM +0000 "Elwell, John" 
<[email-masked]> wrote:

> There seem to be some differences of opinion concerning the use of
> P-Asserted-Identity (PAI) in a response. In particular, this is delaying
> the progress of draft-ietf-sipping-qsig2sip, which makes use of PAI in a
> 200 OK to convey the connected party identity received from the QSIG
> network. The same situation is likely to be encountered when interworking
> with other legacy signalling systems.
>
> It is my opinion that PAI can be used in a 200 OK to assert the identity
> of the connect party. Moreover, it can be inserted by a gateway UAS and,
> unless subject to privacy, can be passed on even to untrusted entities
> including the UAC.
>
> My evidence for assuming this is as follows:
>
> 1. RFC 3325: In section 5, 2nd paragraph it states:
> "If the proxy receives a message (request or response) from a node that it
> trusts, it can use the information in the P-Asserted-Identity header
> field, if any, as if it had authenticated the user itself."
> There is nowhere that forbids the use of P-Asserted-ID in a response,
> although there are places in the RFC that mention procedures for a request
> without mentioning a response. In many places it talks about "message",
> which, according to the text above, means request or response.
>
> 2. RFC 3324 clause 5 clearly states that PAI in INVITE identifies the
> calling user, PAI in a 180 response the ringing user and PAI in 200 OK the
> user who answered the call. RFC 3325 is supposed to meet the requirement
> of RFC3324.
>
> I have seen a number of arguments against the use of PAI in a response:
>
> a) It has been suggested that a PAI in a response represents the identity
> of the entity that issued the request. This does not hold water. It
> clearly would be in contradiction to clause 5 of RFC3324 and there is
> nowhere in RFC3324 or RFC3325 that suggests echoing in a response the PAI
> in the request.
>
> b)It has been suggested that there would need to be corresponding privacy
> requirements for identity information in a response. However, RFC 3323
> does indeed address privacy in responses. See last paragraph of section 3:
> "It may be desirable to restrict identity information on both requests and
> responses.  Initially, it might seem unusual to suggest that a response
> has privacy concerns - presumably, the originator of the request knows
> who they were attempting to contact, so the identity of the respondent
> can hardly be confidential.  However, some personal information in
> responses (such as the contact address at which the respondent is
> currently registered) is subject to privacy concerns and can be addressed
> by these mechanisms."
> Also see section 4.2, which states:
> "...this document defines a new SIP header, Privacy, that can be used to
> specify privacy handling for requests and responses."
>
> c)It has been argued that using PAI in a response may cause an existing
> implementation to do the wrong thing with respect to privacy, e.g., if
> privacy is required by the caller, a proxy may apply this to the connected
> user's identity in the response as well. I don't think this is a likely
> scenario in view of RFC 3323's coverage of privacy in requests and
> responses.
>
> d)Also it has been suggested that an existing UAS may not take care to
> request privacy in a response, not realising that a proxy might add a PAI.
> Again, since RFC 3323 covers privacy in both requests and responses, any
> UA implementation that supports privacy in requests should also support
> privacy in responses.
>
> e) It has been pointed out that a proxy cannot reject a response if the
> PAI is wrong. I don't believe this matters - it should be sufficient for
> the proxy just to strip out a PAI that is wrong.
>
> In conclusion, I see evidence that PAI can be used in a response to assert
> the ID of the connected party and no solid evidence to the contrary.
>
> John Elwell ([email-masked])
>
> _______________________________________________
> 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

Subject: Use of P-Asserted-Identity in a response
From: "Elwell, John" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Fri, 02 Jan 2004 16:11:21 +0000

There seem to be some differences of opinion concerning the use of
P-Asserted-Identity (PAI) in a response. In particular, this is delaying the
progress of draft-ietf-sipping-qsig2sip, which makes use of PAI in a 200 OK
to convey the connected party identity received from the QSIG network. The
same situation is likely to be encountered when interworking with other
legacy signalling systems.

It is my opinion that PAI can be used in a 200 OK to assert the identity of
the connect party. Moreover, it can be inserted by a gateway UAS and, unless
subject to privacy, can be passed on even to untrusted entities including
the UAC.

My evidence for assuming this is as follows:

1. RFC 3325: In section 5, 2nd paragraph it states:
"If the proxy receives a message (request or response) from a node that it
trusts, it can use the information in the P-Asserted-Identity header field,
if any, as if it had authenticated the user itself."
There is nowhere that forbids the use of P-Asserted-ID in a response,
although there are places in the RFC that mention procedures for a request
without mentioning a response. In many places it talks about "message",
which, according to the text above, means request or response.

2. RFC 3324 clause 5 clearly states that PAI in INVITE identifies the
calling user, PAI in a 180 response the ringing user and PAI in 200 OK the
user who answered the call. RFC 3325 is supposed to meet the requirement of
RFC3324.

I have seen a number of arguments against the use of PAI in a response:

a) It has been suggested that a PAI in a response represents the identity of
the entity that issued the request. This does not hold water. It clearly
would be in contradiction to clause 5 of RFC3324 and there is nowhere in
RFC3324 or RFC3325 that suggests echoing in a response the PAI in the
request.

b)It has been suggested that there would need to be corresponding privacy
requirements for identity information in a response. However, RFC 3323 does
indeed address privacy in responses. See last paragraph of section 3:
"It may be desirable to restrict identity information on both requests and
responses.  Initially, it might seem unusual to suggest that a response has
privacy concerns - presumably, the originator of the request knows who they
were attempting to contact, so the identity of the respondent can hardly be
confidential.  However, some personal information in responses (such as the
contact address at which the respondent is currently registered) is subject
to privacy concerns and can be addressed by these mechanisms."
Also see section 4.2, which states:
"...this document defines a new SIP header, Privacy, that can be used to
specify privacy handling for requests and responses."

c)It has been argued that using PAI in a response may cause an existing
implementation to do the wrong thing with respect to privacy, e.g., if
privacy is required by the caller, a proxy may apply this to the connected
user's identity in the response as well. I don't think this is a likely
scenario in view of RFC 3323's coverage of privacy in requests and
responses.

d)Also it has been suggested that an existing UAS may not take care to
request privacy in a response, not realising that a proxy might add a PAI.
Again, since RFC 3323 covers privacy in both requests and responses, any UA
implementation that supports privacy in requests should also support privacy
in responses.

e) It has been pointed out that a proxy cannot reject a response if the PAI
is wrong. I don't believe this matters - it should be sufficient for the
proxy just to strip out a PAI that is wrong.

In conclusion, I see evidence that PAI can be used in a response to assert
the ID of the connected party and no solid evidence to the contrary.

John Elwell ([email-masked])

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 22 Feb 2004 22:24:21 -0800

I think the attached email thread more or less makes exactly my point. I am
not at all arguing that 3325 forbids PAI in response.  That was never the
intention - but 3325 certainly does not say what it means in a response or
how to make it work to something useful or what the useful thing you can do
is. It does not say if PAI in a response is the identity of the UAS or the
UAC. It does not deal with the issue of how you authenticate a response.
There is a bunch of other things it does not deal with.  The pure amount of
language lawyer conjecture in the email thread makes it clear that 3325 does
not define what it means.

If you want to clearly define what PAI in a response means in some document
(qsig or another one), I've got no problem with that - I want to solve this
problem - but 3325 does not define what it means or how to make it work to
accomplish some useful goal.

Cullen

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