Re: [Sip] Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

["Mary Barnes" <mary.barnes at nortel.com>]

Yes, we can plan on doing so in the revisions, once we actually agree to
where we're going with both docs in terms of supporting the target-uri
solution requirements.

Mary. 

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:drage at alcatel-lucent.com] 
Sent: Thursday, March 12, 2009 11:41 AM
To: Barnes, Mary (RICH2:AR00); Dean Willis; Shida Schubert
Cc: sip at ietf.org
Subject: RE: [Sip] Fwd:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of 
> Mary Barnes
> Sent: Wednesday, March 11, 2009 4:27 PM
> To: Dean Willis; Shida Schubert
> Cc: sip at ietf.org
> 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:dean.willis at softarmor.com]
> Sent: Wednesday, March 11, 2009 1:38 AM
> To: Shida Schubert
> Cc: sip at ietf.org 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 
> sip-implementors at cs.columbia.edu for questions on current sip Use 
> sipping at ietf.org for new developments on the application of sip
>