Subject: Re: [Sip] UPDATE and P-Asserted-ID

From: Rohan Mahy <[email-masked]>
Date: Fri, 6 Jun 2003 17:28:34 -0700

On Friday, May 23, 2003, at 03:21 AM, Mark Watson wrote:

> Jonathan's approach seems reasonable, and since P-Asserted-Id just 
> represents the identity of the originator of the *message*

i think you are correct, that the spec means the originator of the 
message, but I do not this is especially clear. i was not sure about 
this.  i thought it was just the initiator of the dialog. After reading 
through RFC 3325 three times, the only thing that strongly indicated 
this was the case was the list of which methods could contain the 
header.  It is unfortunate that UPDATE was not included, since this is 
one of the places using P-Asserted-Id makes the most sense.

thanks,
-rohan

> we could expect it to change during a dialog - I suppose there is a 
> philosphical question that if the identity of the SIP UAS changes, 
> does that mean it is now a logically different UAS and so a new dialog 
> should be established ? even if it's the same physical device so that 
> all the state needed to maintain a single dialog is still available ?? 
> I guess this is the case when call forward/transfer happens downstream 
> of a SIP->X gateway.
>
> Equally, were a device to de-register and re-register with a new 
> Address Of Record, does this represent an 'identity change' for that 
> UA ? Could it meaningfully update its identity in any ongoing dialogs 
> > ?
>
> I think there should be scope for individual headers to specify that 
> their state cannot be updated mid-dialog. Not having looked through 
> all the 'such headers' referred to by Jonathan (not even knowing what 
> this list is!) we can't rule out that the meaning of a mid-dialog 
> update for one of these might not be well-defined i.e. it has no 
> sensible meaning or is ambiguous. In those cases we would need to rule 
> out mid-dialog updates, or define the meaning of them for that header.
>
> ...Mark
>
>
>
> > -----Original Message-----
> > From: Michael Thomas [mailto:[email-masked]]
> > Sent: 19 May 2003 21:18
> > To: Jonathan Rosenberg
> > Cc: Elwell, John; 'Rohan Mahy'; 'Drage, Keith (Keith)'; 
> [email-masked]'
> > Subject: Re: [Sip] UPDATE and P-Asserted-ID
> >
> >
> > Jonathan Rosenberg writes:
> >  > 1. Each header field that conveys dialog-associated state would
> >  > indicate whether or not that state is updated by a target
> > refresh request.
> >  >
> >  > 2. We specify a blanket rule for all such headers that
> > their state is
> >  > updated by a target refresh request (absence of a header
> > would imply
> >  > no update).
> >  >
> >  > 3. We specify a blanket rule for all such headers that
> > their state is
> >  > never updated by a target refresh request.
> >  >
> >  > 4. We specify a default rule for all such headers, but allow
> >  > individual headers to override it.
> >  >
> >  >
> >  > In the interests of simplicity I would tend to lean
> > towards (2). The
> >  > best place for this, of course, is rfc 3261, in which case
> > we should
> >  > treat this as a bug against the spec.
> >
> > This seems quite reasonable to me as well --
> > special casing "initial" from subsequent dialog
> > seems pretty fraught. The only reason that I can
> > think of why you might want to do that is when the
> > state assembly/teardown of a mid-session change
> > was so onerous and/or ambiguous to other state
> > that it was prudent to set up the state once and
> > leave it be. It doesn't seem to me that that's the
> > case here, but I'm hardly an expert.
> >
> >        Mike
> > _______________________________________________
> > 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

---

From: "Christer Holmberg (LMF)" <[email-masked]>
Date: Sat, 7 Jun 2003 09:47:23 +0200

Hi,

There currently are a number of headers where the sender or a request, and the initiator of a dialog, can insert some kind of identity of themselves. They are:

Contact
From
In-Reply-To
Reply-To
P-Asserted-Identity

etc

In most cases the spec(s) do define what they can be used for, but not really what they identify (user, device, etc). Maybe some clarification is needed for that?

I also agree that we need to define which headers are allowed to be changed/updated during a session, and what it really means from a dialog point of view.

Regards,

Christer Holmberg
Ericsson Finland

> From: Rohan Mahy [mailto:[email-masked]]
> Sent: 7. kesäkuuta 2003 3:29
> To: Mark Watson
> Cc: 'Michael Thomas'; Jonathan Rosenberg; Elwell, John; 'Drage, Keith
> (Keith)'; [email-masked]'

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 09 Jun 2003 10:49:16 +0100

Section 5 of RFC3325 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.

   If there is no P-Asserted-Identity header field present, a proxy MAY
   add one containing...."

I take this as meaning that P-Asserted-Id can be sent in requests or
responses. This capability is made use of in draft-ietf-sipping-qsig2sip-02
sections 9.1.3 and 9.2.3.

John Elwell ([email-masked])

> Sent: 07 June 2003 01:29