Hi John,

>I guess what still confuses me is, when both Target and P-CPI 
>are used, which comes first, i.e., which represents the 
>earlier target? When I read the draft, I thought Target was 
>earlier. From various clarifying emails I now get the 
>impression that Target is later. Can you confirm?

I am not sure what you mean by "earlier" target. 

Target, if present, always represents the current target. A receiving
entity that receives a request without a Target header has to assume
that the Request-URI represents the current target. When no Target
header is available on the request then the Target is inserted when a
reroute is performed.

P-CPI is ONLY used to maintain the R-URI which is rewritten by the
contact of the UAS. I.e. by the home proxy which is usually at the end
of a chain of proxies.

When both Target and P-CPI are used: Target always represents the
current target. P-CPI always represents the AOR received by the home
proxy which may in some cases be the same as the current target but it
may also be the last route (not equal to the current target) taken to
deliver the request. 

>Picking up on Francois' point about History-Info, with the 
>introduction of Target and P-CPI we do indeed have a lot of 
>URIs, and of course History-Info can already convey all these 
>URIs and any others. The difference is that History-Info does 
>not give particular semantics to each of the URIs it conveys 
>- they are simply a succession of targets.

Yes, we agree with your analysis regarding History-Info. The
UA-loose-draft discusses further issues with using History-Info.

>With Target and P-CPI we are aiming to define specific 
>semantics. I am concerned whether we will be able to define 
>these semantics tightly enough to ensure consistent 
>implementations.

Target always represents the current target. See above.

P-CPI does not represent the current target in all cases. See above.

>The more URIs we try to define, the harder it will be to assign each
one a clearly distinguishable meaning. I hope the next draft will help.

In the next version of the draft I will remove as much as possible about
P-CPI, in order not to cause confusion. I will only keep some text where
I describe the semantical difference between Target and P-CPI.

I also do agree with one of your previous comments, that we should
clarify the meaning of all the URIs we're using - and that should be
done no matter if we adopt Target or not.

Regards.

Christer














> > -----Original Message-----
> > From: Christer Holmberg [mailto:[EMAIL PROTECTED]
> > Sent: 15 January 2008 08:48
> > To: Francois Audet
> > Cc: [email protected]; DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John
> > Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS 
> > via proxy
> > 
> > 
> > Hi,
> > 
> > P-CPI could probably be useful in some cases, in addition to Loose 
> > Route/Target. And, as the draft says, P-CPI will still have 
> to be used 
> > in IMS, because there are procedures defined for it.
> > 
> > However, again, the purpose of the draft was to provide an 
> alternative 
> > to the Loose Route alternative, and that alternative is Target only.
> > 
> > I am working on an updated version of the draft to make that more 
> > clear.
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > 
> > 
> > >Hum. I guess then P-Called-ID would then be useful with 
> Loose-route 
> > >as well (although now I'm thinking that History-Info covers it).
> > > 
> > >I think explaining all that in great and precise details, with a 
> > >concrete example would be very useful.
> > > 
> > >And then we could compare P-Target with Loose-route. 
> > 
> > 
> > 
> > 
> > 
> > > 
> > > > -----Original Message-----
> > > > From: Christer Holmberg [mailto:[EMAIL PROTECTED]
> > > > Sent: Monday, January 14, 2008 03:56
> > > > To: Audet, Francois (SC100:3055)
> > > > Cc: [email protected]; DRAGE, Keith (Keith); Paul Kyzivat; 
> Elwell, John
> > > > Subject: RE: [Sip] RE: Delivering request-URI and
> > parameters to UAS
> > > > via proxy
> > > > 
> > > > 
> > > > Hi Francois,
> > > > 
> > > > >I think what you meant by Target was more the "Current" 
> > > > >target as opposed to the Initiatl Target.
> > > > 
> > > > Yes.
> > > >  
> > > > >And if that's the case, then I don't see why it is
> > different from
> > > > >P-Called-ID (although I might be missing something 
> with what the 
> > > > >P-Called_ID is supposed to be).
> > > > 
> > > > In the draft we try to explain the difference. But, we are
> > > working on
> > > > the text to make it more clear.
> > > > 
> > > > The P-CPI is inserted when the R-URI is rewritten by 
> the Contact 
> > > > address of the UAS. RFC3455 calls that operation
> > > "retargeting", but we
> > > > don't think that is the definition for retarget used in the 
> > > > ua-loose-route draft, which says:
> > > > 
> > > > "When a home proxy receives a request and accesses a
> > > location service,
> > > > the resulting contact(s) obtained from the location service are 
> > > > considered the last hop in the route towards the entity
> > > addressed by
> > > > the Request-URI.  Since that target, almost by definition,
> > > can claim
> > > > the identity of the URI prior to translation, the operation
> > > is one of
> > > > routing and not retargeting."
> > > > 
> > > > So, if we follow the definitions in the ua-loose-route
> > draft, P-CPI
> > > > would be inserted due to a reroute - not retarget.
> > > > 
> > > > But, no matter whether we call it retarget or reroute,
> > the point is
> > > > that the P-CPI is inserted when the R-URI is rewritten with the 
> > > > Contact address of the UAS. The scope of Target is wider
> > than that,
> > > > and can be used in any retargeting situation.
> > > > 
> > > > Regards,
> > > > 
> > > > Christer
> > > > 
> > > > 
> > > 
> > 
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to