Keith, If this wasn't a consensus call: http://www.ietf.org/mail-archive/web/sipping/current/msg16231.html then what do you mean? John > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@xxxxxxxxxxxxxxxxxx] > Sent: 23 October 2008 18:10 > To: Elwell, John; sipping@xxxxxxxx > Subject: RE: Decision needed on final issue > withdraft-ietf-sipping-update-pai-07 > > 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
