[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Terminology (was RE: Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
So, by "target-uri concept" are you referring to the solution in the
current target-uri draft or the application usage as such in the
target-uri document (which is what I was referring to)?
Yes, the problem is that SIP doesn't differentiate the various
mechanisms by which a request-URI may be changed, which is what some of
the updated text in 4244bis is trying to do and why we need precise
terms. I think we all agree that.
I honestly don't care what we call the tag, as long as we're clear about
the functionality.
Mary.
-----Original Message-----
From: Hans Erik van Elburg [mailto:ietf.hanserik at gmail.com]
Sent: Wednesday, March 11, 2009 4:40 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Shida Schubert; sip at ietf.org
Subject: Re: Terminology (was RE: [Sip] Fwd: I-D
ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
The target-uri concept when defined properly is entirely application
agnostic.
When one uses History-Info or another header as a vehicle for this
information then it still can be considered application agnostic as any
application can use this information as it likes.
From SIP perspective all the Request-URI rewrites look the same, that
is what brought us discussing this in the first place.
/Hans Erik
Mary Barnes wrote:
> And, I think the big issue with the terminology is that 4244bis is
> application agnostic, so it is tagging what happens to the URIs
> (why/how the specific URI was overwritten). Whereas, specific
> applications can derive information, such as what "is" the real
> "target" for the request, from the History-Info header. So, IMHO,
> it's a matter of the target-uri document specifying that the last
> entry tagged by whatever name we come up with "is" the real "target"
> for the request. I believe it's up to the applications to describe
> how they make use of the History-Info and not for the History-Info to
> describe how applications can use it. History-Info purely reflects
> what happened from a SIP Protocol perspective and should not imply any
> application semantics. Indeed the intent of section 5 of 4244 was to
> inform the applications how they should decribe their usage of the
> header.
>
> Mary.
> Note: I changed the subject to hopefully make this topic easier to
> keep track of.
>
> ----------------------------------------------------------------------
> --
> *From:* Hans Erik van Elburg [mailto:ietf.hanserik at gmail.com]
> *Sent:* Wednesday, March 11, 2009 3:59 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
>
> One of the problems that made the discussion quite tedious is the
> complete inversed meaning of the terms "retarget" and "reroute"
> between 4244bis and target-uri factions have.
>
> Conclusion was that the terminology need to be properly defined and
> some attempt was made to start such activity.
>
> On 3. I have strong concerns when we start tagging the URI as to how
> they come about "retarget"/"mapped conficuration" etc. It is better to
> embellish them with a tag that just represents there meaning for
> example "istarget" or "hop". For the following reasons:
> 1. It is much more intuitive for the user of this information, its
> meaning can basically be guessed.
> 2. Such meaning also probably survives application in other problem
> spaces that we had not foreseen when introducing the concept.
>
> The solution that is described now in the target-URI delivery draft
> is not yet complete, it does not solve the freephone use case for
> example and in its current form it will deliver exactly the same
> target-URI as that which would be delivered by the P-Called-Party-ID
> header. Contrary to what the draft says. So some work is needed still.
>
> /Hans Erik van Elburg
>
>
> On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert <shida at ntt-at.com
> <mailto:shida at ntt-at.com>> wrote:
>
>
> We have submitted the updated target-uri draft based on the
comments
> submitted to the list and comments received at IETF73.
>
> I have taken over as editor as Jonathan didn't have the cycles to
> update the draft, with Francois, Christer and Hans Erick as
> additional
> co-authors and great deal of help from Mary.
>
> The following summarizes the changes made to the target-uri
document
> 1. Added use-case for toll-free number back
> 2. Added definition of "retarget" operation.
> 3. Removed a reference to URN
> 4. Added a text discussing the difference to P-Called-Party-Id
> 5. Changed parameter name from "target" to "istarget"
>
> Note, that the target-uri document still contains the normative
> text for the
> History-Info header.
>
> In addition, Mary (with Francois as co-author) has submitted a
> rfc4244bis, with the following changes:
> 1. Incorporated the normative aspects of the target-uri document
> into the existing normative text in RFC 4244 - the functionality
is
> virtually identical (as is some of the text) as the HI based
solution
> described in the target-uri document. It's important that the
> solution
> be integrated into RFC 4244 as it MUST work and be based on the
> normative
> aspects of RFC 4244.
> 2. Added the use cases from target-uri the the summary
> in the overview of rfc4244bis.
> 3. Added an additional requirement to capture the "target-uri"
> information.
> 4. Fixed an error in the RFC 4244 ABNF and added "retarget"
parameter.
> 5. Added a more simplified example.
>
>
> We had some very long offline exchanges as to the best way forward
and
> remaining work for both documents.
>
> Some of the issues identified are:
>
> ::Issues::
> 1. Should we remove the normative text from target-uri and
progress
> 4244bis along with the target-uri document to meet the
> chartered
> SIP WG milestone?
>
>
> 2. Name of the parameter.
> At the last meeting, parameter "target" was said
inappropriate
> because voicemail-uri spec already defines a parameter
called
> "target" which also can be found in hi-entry, thus
potentially
> causing confusion.
>
> Currently the target-uri draft uses "istarget" and 4244bis
uses
> "retarget" but we could never come to
> a consensus on what name is appropriate. Other suggestions
have
> included the following:
> "target-identity" (someone didn't like that "identity" is
> also a SIP header)
> "reg-uri" (can be paired with "mapped-uri" for item 3
below)
> "aor"
> "jibberish"
> etc.
>
> 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.
>
> 3. Related to the last point in item 2 above, it has been
> proposed that
> we differentiate the hi-entries even more by defining
> separate parameters
> for registered and configured/mapped contacts.
> Currently when the R-URI is translated to a URI which is
> either derived
> from location service lookup(registered by UA) or from
mapping
> table, there is no differentiation as to how the URI was
> derived once it is
> added to the list of potential targets.
>
> The general consensus of the authors of the two documents was
> that it may
> be useful for some services to have the hi-entries tagged
> with the
> more specific information.
>
> And, of course, this gets us into another naming contest. In
> the end, the naming
> is not so important as long as the term isn't too overloaded
> and it is defined
> precisely in the document(s).
>
> We would appreciate WG feedback on these issues and any other
> comments on
> the two documents prior to IETF-74.
>
> Regards,
> Shida and Mary.
>
>
>
> Begin forwarded message:
>> *From: *Internet-Drafts at ietf.org
<mailto:Internet-Drafts at ietf.org>
>> *Date: *March 10, 2009 2:30:01 AM JST
>> *To: *i-d-announce at ietf.org <mailto:i-d-announce at ietf.org>
>> *Subject: **I-D
>> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt *
>> *Reply-To: *internet-drafts at ietf.org
>> <mailto:internet-drafts at ietf.org>
>>
>> A New Internet-Draft is available from the on-line
Internet-Drafts
>> directories.
>>
>>
>> Title
>> : Delivery of Request-URI Targets to User Agents
>> Author(s)
>> : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. Schubert
>> Filename : draft-rosenberg-sip-target-uri-delivery-01.txt
>> Pages
>> : 16
>> Date
>> : 2009-3-9
>>
>> When a Session Initiation Protocol (SIP) proxy receives a request
>> targeted at a URI identifying a user or resource it is
responsible
>> for, the proxy translates the URI to a registered or configured
>> contact URI of an agent representing that user or resource. In
the
>> process, the original URI is removed from the request.
>> Numerous use
>> cases have arisen which require this information to be
delivered to
>> the user agent. This document describes these use cases and
>> defines
>> an extension to the History-Info header field which allows it
to be
>> used to support those cases.
>>
>> A URL for this Internet-Draft is:
>>
>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-de
>> livery-01.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
> Content-Type: text/plain<BR>Content-ID:
> <2009-3-9102756.I-D at ietf.org
> <mailto:2009-3-9102756.I-D at ietf.org>><BR><BR>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce at ietf.org <mailto:I-D-Announce at ietf.org>
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> _______________________________________________
> 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
> <mailto:sip-implementors at cs.columbia.edu> for questions on current
sip
> Use sipping at ietf.org <mailto:sipping at ietf.org> for new
> developments on the application of sip
>
>