Subject: Re: [Sipping] draft-ietf-update-pai-01 available - PAI in ACK

From: "Elwell, John" <[email-masked]>
Date: Fri, 20 Jun 2008 14:08:57 +0100

Brett,

Apologies for the very late response to this. See below.

John 

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]] 
> Sent: 19 May 2008 18:56
> To: Elwell, John; [email-masked]
> Subject: RE: [Sipping] draft-ietf-update-pai-01 available - PAI in ACK
> 
> > I would be quite happy to relax it to cover any 
> > request (and any response), if this is what 
> > the WG desires. Other opinions?
> 
> In general the more locations that content updates are allowed, the
> higher potential for race conditions, ambiguities, and 
> interoperability
> problems.  However since PAI is hopefully a header which 
> doesn't change
> much within a dialog, I don't have a strong opinion concerning the
> topic.  
> 
> Unfortunately one of the problems with UPDATE, re-INVITE, etcetera is
> that it is not always clear what is trying to be updated and what was
> successfully updated.  Allowing things to be updated by responses and
> additional requests just adds to the problem and race conditions.
[JRE] I agree there is a general problem with UPDATE and re-INVITE. The
omission of information from such a request (when it as present in an
earlier message, e.g., the original INVITE request or response) could
either mean that the information has not changed (therefore the previous
value is still valid) or that the previous value is no longer
applicable, or that nothing can be inferred about the whether the
previous value is still valid or not. I think for the particular case of
PAI we had some discussion on this earlier, and I think the general
conclusion was that the presence or absence of PAI relates to that
particular request, and in the absence of PAI, nothing can be inferred
about the source of that particular message.

> 
> Hopefully nobody is wanting to update a dialog's PAI by 100 
> and 300-699
> responses.  Hopefully nobody is wanting to update PAI by 
> CANCEL, CANCEL
> responses, and ACK-for-non-2xx.
[JRE] The present draft does not talk about updating the identity for a
dialog - it confines itself to inclusion of PAI in requests and response
to indicate the asserted source of those requests and responses. The
draft title ("update-pai") originates from the fact that the draft
updates RFC 3325.

>
> For race condition reasons, I prefer PAI processing not be assumed
> successful if PAI included within PRACK, PRACK 2xx, or ACK.
[JRE] The concept of assuming PAI processing to be successful does not
arise within the draft.

[JRE] The proposal from several people is simply to allow PAI in any
request or response, simply to indicate the source of that request or
response. Would you have any objection to this?

> -brett
_______________________________________________
Sipping mailing list  https://www.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

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 20 Jun 2008 10:32:29 -0400

Thanks for the response.  Reply inline.

> > > I would be quite happy to relax it to cover 
> > > any request (and any response), if this is what 
> > In general the more locations that content 
> > updates are allowed, the higher potential for race 
> > conditions, ambiguities, and interoperability 
> > problems.  However since PAI is hopefully a header 
> > which doesn't change much within a dialog, I don't 
> > have a strong opinion concerning the topic.
> > 
> > Unfortunately one of the problems with UPDATE, 
> > re-INVITE, etcetera is that it is not always clear 
> > what is trying to be updated and what was 
> > successfully updated.  Allowing things to be updated 
> > by responses and additional requests just adds to 
> > the problem and race conditions.
> 
> [JRE] I agree there is a general problem with UPDATE and 
> re-INVITE. The omission of information from such a request 
> (when it as present in an earlier message, e.g., the original 
> INVITE request or response) could either mean that the 
> information has not changed (therefore the previous value is 
> still valid) or that the previous value is no longer 
> applicable, or that nothing can be inferred about the whether 
> the previous value is still valid or not. I think for the 
> particular case of PAI we had some discussion on this 
> earlier, and I think the general conclusion was that the 
> presence or absence of PAI relates to that particular 
> request, and in the absence of PAI, nothing can be inferred 

It sounds like there is a disconnect concerning impact of a
received/sent PAI upon the dialog.  After the request/response
containing PAI is successfully processed, isn't it still considered
associated with the call's dialog until updated?

> > 
> > Hopefully nobody is wanting to update a dialog's 
> > PAI by 100 and 300-699 responses.  Hopefully nobody 
> > is wanting to update PAI by CANCEL, CANCEL responses, 
> > and ACK-for-non-2xx.
> 
> [JRE] The present draft does not talk about updating the 
> identity for a dialog - it confines itself to inclusion of 
> PAI in requests and response to indicate the asserted source 
> of those requests and responses. The draft title 
> ("update-pai") originates from the fact that the draft 
> updates RFC 3325.

I could be misinterpreting it; however the draft appears to indicate
that the received PAI updates PAI of the dialog instead only applying to
this request/response.  See draft-ietf-sipping-update-pai-02 sections
3.2, 3.6, 3.7, and 4.1.1.

> >
> > For race condition reasons, I prefer PAI processing 
> > not be assumed successful if PAI included within PRACK, 
> > PRACK 2xx, or ACK.
>
> [JRE] The concept of assuming PAI processing to be successful 
> does not arise within the draft.
>
> [JRE] The proposal from several people is simply to allow PAI 
> in any request or response, simply to indicate the source of 
> that request or response. Would you have any objection to this?

I have no objections to it.  However I'm baffled as to why PAI isn't
associated with the dialog.
_______________________________________________
Sipping mailing list  https://www.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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Jun 2008 10:43:56 -0400

Replying to the discussion as a whole, not any particular part of it:

I think PAI can only be guaranteed to apply to the request or response 
in which it appears. A particular UA (or proxy I guess) may choose to 
infer the identity of subsequent messages in the same dialog that don't 
contain PAI, or of media received in the corresponding session. But that 
is a local decision based on understanding the context well enough to 
infer that those things must be from the same source. In general that 
cannot be guaranteed.

For that reason I think it is better if PAI is allowed in any request or 
response. Then it is up to the element that inserts it to decide on what 
basis to do so.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 20 Jun 2008 16:53:49 +0100

Brett,

As Paul suggested in the message he posted earlier today, it is up to
the UA to decide how to interpret PAI in the context of a dialog - the
draft just allows PAI in requests and responses, to indicate the source
of those requests and responses. The same is true for RFC 3325, which
does not even mention dialogs. If there are misleading statements in the
draft, I will need to fix these at the next version.

John 

> Sent: 20 June 2008 15:32

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 20 Jun 2008 13:01:37 -0400

John,

I agree that it might be nice to include PAI within all requests and
responses from a transaction perspective.  However completely leaving it
to the receiver to determine the call/dialog impacts as the PAI changes
within various requests and responses does not sound very interoperable.
I'd prefer the clarification be within draft-ietf-update-pai instead of
requiring a BCP or vendor clarification.

Thanks for the response,
Brett

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Friday, June 20, 2008 11:54 AM
> To: Brett Tate; [email-masked]
> As Paul suggested in the message he posted earlier today, it 
> is up to the UA to decide how to interpret PAI in the context 
> of a dialog - the draft just allows PAI in requests and 
> responses, to indicate the source of those requests and 
> responses. The same is true for RFC 3325, which does not even 
> mention dialogs. If there are misleading statements in the 
> request (and any 
> > > > > response), if this is what the WG desires. Other opinions?
> > > > 
> > > > In general the more locations that content updates are allowed, 
> > > > the higher potential for race conditions, ambiguities, and 
> > > > interoperability problems.  However since PAI is hopefully a 
> > > > header which doesn't change much within a dialog, I 
> don't have a 
> > > > strong opinion concerning the topic.
> > > > 
> re-INVITE, etcetera 
> > > > is that it is not always clear what is trying to be updated and 
> > > > what was successfully updated.  Allowing things to be 
> updated by 
> > > > responses and additional requests just adds to the problem and 
> > > > race conditions.
> > > 
> re-INVITE. 
> > > The omission of information from such a request (when it 
> as present 
> > > in an earlier message, e.g., the original INVITE request or 
> > > response) could either mean that the information has not changed 
> > > (therefore the previous value is still valid) or that the 
> previous 
> > > value is no longer applicable, or that nothing can be 
> inferred about 
> > > the whether the previous value is still valid or not. I think for 
> > > the particular case of PAI we had some discussion on this 
> earlier, 
> > > and I think the general conclusion was that the presence 
> or absence 
> > > of PAI relates to that particular request, and in the absence of 
> > > PAI, nothing can be inferred about the source of that particular 
> > > message.
> > 
> > > > Hopefully nobody is wanting to update a dialog's PAI by 100 and 
> > > > 300-699 responses.  Hopefully nobody is wanting to 
> update PAI by 
> > > > CANCEL, CANCEL responses, and ACK-for-non-2xx.
> > > 
> > > [JRE] The present draft does not talk about updating the identity 
> > > for a dialog - it confines itself to inclusion of PAI in requests 
> > > and response to indicate the asserted source of those 
> requests and 
> > > responses. The draft title
> updates RFC 
> > > 3325.
> > that the received PAI updates PAI of the dialog instead 
> only applying 
> > to this request/response.  See draft-ietf-sipping-update-pai-02 
> > sections 3.2, 3.6, 3.7, and 4.1.1.
> > 
> > 
> > > >
> > > [JRE] The concept of assuming PAI processing to be 
> successful does 
> > > not arise within the draft.
> > >
> > > request or response, simply to indicate the source of 
> that request 
> > > or response. Would you have any objection to this?
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Jun 2008 15:30:59 -0400

Brett,

The problem is that in general there are no guarantees that all messages 
over a dialog are from the same source.

If you insist on a requirement that a PAI on one message in the dialog 
means all subsequent messages in the dialog are from the same source, 
then you will constrain insertion of PAI to those who have some 
(presumably cryptographic) means of assuring the source for all those 
messages will be the same. So it might work for IMS with its security 
context, but maybe nowhere else.

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 24 Jun 2008 11:50:17 -0400

Thanks for the responses.

I agree that the PAI can change within dialog (or as currently proposed
even within the context of a transaction or its CANCEL).

The current proposal of allowing PAI within all requests and responses
makes it harder to successfully communicate an updated PAI (in context
of a dialog) because of potential race conditions and expectations of
the receiver to allow it to update the dialogs PAI.

If others don't think this is an issue, I'm ok with the proposal to not
discuss PAI in the context of a dialog.  Similarly, I'm ok with allowing
PAI within all requests and responses.

Thanks again,
Brett

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 24 Jun 2008 16:56:49 +0100

Brett,

Thanks. I will start almost immediately to update the draft to allow PAI
in any request/response, so if anyone has any objections, please say so
now.

John 

> Sent: 24 June 2008 16:50
> To: Paul Kyzivat; Elwell, John
> Cc: [email-masked]