Hi Jeroen,
>I think we'll also need a new response code: 4xx I'm confused, too many URIs in request > >Seriously, a solution based on yet another header with an URI IMHO introduces more complexity/confusion than solving the >issue is worth. > >Better to limit the scope of the problem we're trying to >solve and document the known limitations / use cases. If the >problem is to deliver the request URI to a UAS which is >registered with its home proxy, and there is a mechanism by >which the proxy can detect support by the UAS, Jonathan's >solution is fine. I don't think that is the whole problem (if it was, P-Called-Party-ID would probably work just fine). To my understanding it is not necessarily the home proxy of the UAS which rewrites the Request-URI in the use-cases presented in the drafts. It can be another entity in the path - an entity which havs no clue about what the UAS supports or not. Regards, Christer > >> -----Original Message----- > >> From: Elwell, John [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, January 15, 2008 01:20 > >> To: Christer Holmberg; Audet, Francois (SC100:3055) > >> Cc: [email protected]; DRAGE, Keith (Keith); Paul Kyzivat > >> Subject: RE: [Sip] RE: Delivering request-URI and > parameters to UAS > >> via proxy > >> > >> Christer, > >> > >> 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? > >> > >> 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. > >> 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. 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. > >> > >> John > >> > >> > >>> -----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 > > > > > _______________________________________________ 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
