Which is where I was coming from on my offline email to you, i.e. that we should start recording our position of any changes required to RFC 3261 in an appendix. That way we know what changes we need to make to RFC 3261 when we get to make them, even if they are only for alignment of terminology. We can decide later whether the appendix gets published with the update to either RFC 4244 or target-URI or some combined document.
Keith > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Mary Barnes > Sent: Wednesday, March 11, 2009 4:27 PM > To: Dean Willis; Shida Schubert > Cc: [email protected] > Subject: Re: [Sip] Fwd: I-D > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > I don't think it should cause so much concern as I think it > just requires clarifying text and we just need to agree to > more precise > terms: e.g., qualifying the use of "forward" with either > "next hop forwarding" or "request forwarding" for this > particular case. As long as we can be precise in 4244bis, > then that should suffice for now, but whenever 3261 is > updated or bised, then I think the clarifications should be included. > > Mary. > > -----Original Message----- > From: Dean Willis [mailto:[email protected]] > Sent: Wednesday, March 11, 2009 1:38 AM > To: Shida Schubert > Cc: [email protected] List; Barnes, Mary (RICH2:AR00) > Subject: Re: [Sip] Fwd: I-D > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > On Mar 11, 2009, at 1:13 AM, Shida Schubert wrote: > > > > > One reason this is so difficult relates to the > problem statement > > > in target-uri in that > > RFC 3261 doesn't differentiate the mechanism by which the new > > (target) Request-URI is selected. Another issue is > that some of > > > the terminology in > > RFC 3261 is overloaded - e.g., "forwarding" refers both to a > > Proxy > > which does not have responsibility for the domain of the > > request-URI > > in the incoming request, thus the proxy just "forwards" the > > request to > > the next hop AND "forwarding" is used to describe the process > > whereby > > the outgoing request is built and "forwarded" to the > next hop at > > > which > > point the proxy does not know how the new request-uri was > > selected. > > RFC 4244 has attempted to clarify the terms and > attempts to use > > "forward" > > in the context of the former situation and "retarget" for the > > case whereby > > a proxy is responsible for the domain and thus can > use a number > > of > > mechanism to select the new target for the request - e.g., a > > REGISTRAR, > > configured data, etc. > > > > Thanks, Shida. > > I personally would not be averse to an Essential Correction that > corrects the terminology in RFC 3261, but I suspect that will > make many > heads spin around elsewhere in the WG. > > -- > Dean > _______________________________________________ > Sip mailing list https://www.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://www.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
