Hi, 

>I am still confused by the distinction between Target and P-CPI.
> 
>I agree that you have described rules for updating Target 
>that are different from those for updating P-CPI. But it 
>seems to me that is a distinction without a significant 
>difference. For the recipient of the request, the two are 
>used the same way, toward the same end. If anything I would 
>view the rules for Target to be just a bug fix on P-CPI.

You don't update P-CPI. It's inserted by the home proxy, and nothing
else.

The headers have differenct semantics. I don't see that as a bug.

Maybe we could try to change the semantics of P-CPI, and re-define the
header, but that was never my intention when I proposed to use P-CPI.

Regards,

Christer 





>       Paul
> 
> Christer Holmberg wrote:
> > 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