Well I am afraid that the text you have included in the existing version, as detailed below, is not acceptable. I believe it is usable with constraints in responses, and the text implies that any RFC 3325 implementation is not allowed to support it. I do have the discussion, but don't remember a consensus call on this issue. Regards Keith > -----Original Message----- > From: Elwell, John [mailto:john.elwell@xxxxxxxxxxx] > Sent: Thursday, October 23, 2008 3:58 PM > To: DRAGE, Keith (Keith); sipping@xxxxxxxx > Subject: RE: Decision needed on final issue > withdraft-ietf-sipping-update-pai-07 > > Keith, > > The change concerning responses is already made in 07, as a > result of what seemed to be the consensus in SIPPING a couple > of weeks ago, after one of the ADs stated that it would not > stand a chance of getting through IESG. Therefore I > reluctantly made the change in 07. Nobody seemed to be > supporting the retention of the response stuff in there at > the time. It doesn't ban PAI in responses, it just does not > specify them, leaving it for a possible future update if/when > a standardised means of authenticating a UAS is available. > The relevant text is: > <t>RFC 3325 is unclear on the use of P-Asserted-Identity > in responses. In contrast to requests, there is no means in > SIP to challenge a UAS to provide SIP digest authentication > in a response. As a result, there is currently no > standardised mechanism whereby a proxy can authenticate a > UAS. Since authenticating the source of a message is a > pre-requisite for asserting an identity, this document does > not specify the use of the P-Asserted-Identity header field > in responses. This may be the subject of a future update to > RFC 3325. Also this document does not specify the use of the > P-Preferred-Identity header field in responses, as this would > serve no purpose in the absence of the ability for a proxy to > insert the P-Asserted-Identity header field.</t> > > So now I just want to know what to do about CANCEL and ACK. > > John > > > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@xxxxxxxxxxxxxxxxxx] > > Sent: 23 October 2008 15:47 > > To: Elwell, John; sipping@xxxxxxxx > > Subject: RE: Decision needed on final issue > > withdraft-ietf-sipping-update-pai-07 > > > > > We recently > > > agreed to remove specification of PAI in responses > because there is > > > no standardised means of authenticating a UAS. Brett > > > > > > > So what exactly is the change you are making here. > > > > As far as I am concerned RFC 3325 allowed PAI in responses. > There was > > some debate a long while ago on this but that is used by many > > implementations. > > > > In the 3GPP case, it is based on the P-Called-ID header transferred > > internally, i.e. the request was delivered to this terminal > which was > > an authenticated user based on the registration, and a security > > association created at that time. Note that we are making some > > assumptions here, but those assumption are valid in this scenario. > > > > So I do not believe you should be changing the underlying > RFC 3325 in > > this respect. > > > > Regards > > > > Keith > > > > > -----Original Message----- > > > From: sipping-bounces@xxxxxxxx > > > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Elwell, John > > > Sent: Thursday, October 23, 2008 3:18 PM > > > To: sipping@xxxxxxxx > > > Subject: Decision needed on final issue > > > withdraft-ietf-sipping-update-pai-07 > > > > > > I need a decision on one outstanding issue. We previously agreed > > > that PAI could be used in any request. We recently agreed > to remove > > > specification of PAI in responses because there is no > standardised > > > means of authenticating a UAS. Brett Tate pointed out > that likewise > > > there is no standardised means of authenticating a UAC > when it sends > > > CANCEL or ACK (these cannot be challenged, and cannot be > rejected if > > > authentication is wrong). I have so far received no > further opinions > > > on this. To be consistent I believe we have to make exceptions of > > > CANCEL and ACK and say that PAI cannot be used with these methods. > > > > > > If I receive no objections by 26th October I will update > the draft > > > on 27th. > > > > > > 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 > > > > > > _______________________________________________ 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
