The problem with the current words is that this document updates RFC 3325, and therefore by implication any statement of scoping implies a rescoping of RFC 3325. So you actually need to say that this document makes no change to any existing or implied usage of identify in responses as defined by RFC 3325 - or alternatively just don't include any mention of responses at all. But personally I think we should solve the response issue by identifying conditions under which it can be valid - see other mail on this subject. Regards Keith > -----Original Message----- > From: Elwell, John [mailto:john.elwell@xxxxxxxxxxx] > Sent: Friday, October 24, 2008 7:16 AM > To: DRAGE, Keith (Keith); sipping@xxxxxxxx > Subject: RE: Decision needed on final issue > withdraft-ietf-sipping-update-pai-07 > > > > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@xxxxxxxxxxxxxxxxxx] > > Sent: 24 October 2008 02:47 > > To: Elwell, John; sipping@xxxxxxxx > > Subject: RE: Decision needed on final issue > > withdraft-ietf-sipping-update-pai-07 > > > > Wel I certainly could not find that message. > > > > But > > > > That message says remove everything in update PAI on responses. > > > > What you have actually done is put in text on responses > that removes > > it from RFC 3325, at least in my reading. > [JRE] It says that the document does not specify use of PAI > in responses, without actually saying that PAI cannot be used > in responses. > We can certainly try to clarify those words. Maybe instead of > "this document does not specify the use of the > P-Asserted-Identity header field in responses" we should say > that use in responses is outside scope. > > John > > > > > > > Regards > > > > Keith > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@xxxxxxxxxxx] > > > Sent: Thursday, October 23, 2008 6:49 PM > > > To: DRAGE, Keith (Keith); sipping@xxxxxxxx > > > Subject: RE: Decision needed on final issue > > > withdraft-ietf-sipping-update-pai-07 > > > > > > 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
