Hi, >>>I have some questions and comments: >>> >>>- I don't understand your examples in section 3. They are a bit >>>sketchy about the assumptions they are making, and in notation. I get
>>>lost about which referenced component has which address, etc. I am >>>far from convinced that these are problems with appropriate use of >>>the mechanism. >> >>As indicated in chapter 3, one of the main issues/limitations with the >>J'draft solution is that the entity wanting to use it must have >>knowledge whether the next hop also supports it. My understanding from >>off-line discussions I had with Jonathan in Vancouver is also that >>Jonathan agrees to that issue/limitation. >> >>The purpose of the examples is just to show what can go wrong if the >>next hop does not understand the mechanism. But, if we all agree to >>the limitation with the J'draft solution I don't know whether we need >>to spend too much time on the examples. > >The limitation is the limitation. It means that you don't use >the mechanism if you don't know the next hop supports it. So >its useless to speculate what would go wrong if you use the >mechanism with a next hop that doesn't support it. We thought it would be good to show some examples, in case people don't understand WHY the limitation is there. >>>- It seems from your analysis of use cases that it is P-Called-Party >>>that solves many of them, not Target. So both headers seem to be part >>>of the solution. >> >>No, as far as the alternative to the J'draft solution is concerned, >>the alternative is Target. We believe it can be used for all listed >>use-cases. > >I don't understand. Several of them called for using P-CPI. No, we say that there are certain use-case we belive the P-CPI was defined to be used for, but we also say that the Target header can be used for those use-cases. Again, the Target header is our proposal for an alternative to the J'draft solution. Regards, Christer > >> Christer Holmberg wrote: > >>> Hi, > >>> > >>> We have submitted a draft with an alternative proposal. > >>> > >>> It can also be found at: > >>> > >>> > >> > http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-target-uri- > >> d > >>> el > >>> ivery-00.txt > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: DRAGE, Keith (Keith) [mailto:[EMAIL PROTECTED] > >>>> Sent: 9. tammikuuta 2008 18:32 > >>>> To: [email protected] > >>>> Subject: [Sip] RE: Delivering request-URI and parameters > >> to UAS via > >>>> proxy > >>>> > >>>> A reminder of the deadline on the 11th January for submitting > >>>> alternative proposals on the way forward. > >>>> > >>>> Regards > >>>> > >>>> Keith > >>>> > >>>>> -----Original Message----- > >>>>> From: DRAGE, Keith (Keith) > >>>>> Sent: Tuesday, December 04, 2007 3:27 PM > >>>>> To: [email protected] > >>>>> Subject: Delivering request-URI and parameters to UAS via proxy > >>>>> > >>>>> (As WG chair) > >>>>> > >>>>> We have a couple of milestones that we generated as a result of > >>>>> discussion of > >>>>> > >>>>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > >>>>> se-route-01.txt > >>>>> > >>>>> Dec 2007 Delivering request-URI and parameters to UAS via > >>>>> proxy to WGLC > >>>>> Feb 2008 Delivering request-URI and parameters to UAS via > >>>>> proxy to IESG (PS) > >>>>> > >>>>> This work is currently stalled and the editor needs input. > >>>>> > >>>>> The document contains various example scenarios where a > >> solution is > >>>>> required, for which there appears to be no dispute that a > >>>> solution is > >>>>> needed. > >>>>> > >>>>> The document proposes one solution to resolve these example > >>>> scenarios, > >>>>> but this solution is not gaining consensus. At least one other > >>>>> solution has been talked about, but there is no > >>>> documentation on the > >>>>> table. > >>>>> > >>>>> This mail is to identify a deadline for other solutions to > >>>> the example > >>>>> scenarios to be documented as internet drafts, showing how the > >>>>> solution works for those scenarios. This deadline is: > >>>>> > >>>>> January 11th 2008 > >>>>> > >>>>> It is appropriate fo these documents to identify any other > >>>> scenarios > >>>>> where such a solution is appropriate. Any other input is > >>>> also welcome > >>>>> in identifying other scenarios. > >>>>> > >>>>> If we have no such internet-drafts by this deadline, we > >>>> will proceed > >>>>> with completing the solution we have. > >>>>> > >>>>> > >>>>> Regards > >>>>> > >>>>> Keith > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> 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 > >>> > >> > >> _______________________________________________ > >> 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 > _______________________________________________ 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
