Re: Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
Hans Erik van Elburg <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
But that does not solve the freephone service use case. Freephone represents
a use case where the R-URI is replaced with an AoR of user B - not with the
contact of user B.
A calls Bfreephonenumber routed the B (AOR) routed to B's contact.
The target-uri draft is interested in obtaining: Bfreephonenumber as that is
what A used to reach B.
So what we like to see that B UA receives is something like
H-I: Bfreephone; "istarget",\
B,\
contact-B
So you want to get Bfreephonenumber and not B.
In certain situations you are also interested in B, I guess that PBX's
would interested in that to deliver to the correct user. We could
distinguish them like:
H-I: Bfreephone; "istarget",\
B,"aor"\
contact-B
BR,
/Hans Erik van Elburg
On Thu, Mar 12, 2009 at 12:08 PM, Elwell, John <[email protected]>wrote:
> If 'istarget' is used only to identify the value that was overwritten in
> the Request-URI by a contact URI, an alternative approach would be to
> flag the contact URI H-I entry as 'iscontact'. Then the UAS would just
> need to look for the most recent H-I entry that is not marked
> 'iscontact'.
>
> John
>
>
> ________________________________
>
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Hans Erik van Elburg
> Sent: 12 March 2009 08:35
> To: Mary Barnes
> Cc: [email protected]
> Subject: Re: [Sip] Terminology (was RE: Fwd:
> I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
>
>
> Yes, because you are using the 3261 use of target and the
> 4244bis introduced definition of retarget. I thought it was clear that
> we need other words as those definitions don't match the target-uri
> drafts use of the terms. Also they do not suffice to provide a solution
> for the use cases in the target-uri draft.
>
> The 3261 text you refer to is exactly about the case where the
> home proxy overwrites the Request-URI with a new target. This target is
> teh registered contact address. And hence this would be what target-uri
> calls a hop or a route. This case and this is where it gets confusing is
> not a "retarget" in the target-uri draft use of the term.
>
> The target-uri draft states:
>
> "To avoid confusion, we
> refer to a SIP URI that is an address for a user or resource
> as a
> "target" and a SIP URI that is a hop for reaching that user
> as a
>
> "hop".
>
>
> Apparently that does not suffice to avoid confusion.
>
> As for the tagging, speaking about the solution before agreeing
> on the terminology and the problem it should solve is meaningless.
>
> /Hans Erik van Elburg
>
>
>
> On Thu, Mar 12, 2009 at 2:33 AM, Mary Barnes
> <[email protected]> wrote:
>
>
> Responses below [MB].
>
>
> -----Original Message-----
> From: Hans Erik van Elburg
> [mailto:[email protected]]
>
> Sent: Wednesday, March 11, 2009 6:42 PM
> To: Barnes, Mary (RICH2:AR00)
> Cc: Shida Schubert; [email protected]
> Subject: Re: Terminology (was RE: [Sip] Fwd: I-D
> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
>
>
> I was talking about the concept.
>
> The use cases only describe cases where the target-uri
> (lets call that
> current target from now) has been lost when an initial
> request for a
> dialog or standalone request arrives at the UAS.
>
> [MB] And I think this is where the terminology confusion
> starts - I
> don't think of the "lost" target-uri as being the
> "current" target. In
> my mind, the "current" target is reflected by the last
> hi-entry and the
> request-uri in the incoming request at the UAS. If the
> entity that sent
> the request was the entity that added the last hi-entry,
> then the uri in
> that hi-entry is the same as the request-URI in the SIP
> request that
> arrives at the UAS. I refer to the "lost" uri as the one
> that was
> "retargeted" - that's the one the UAS wants to pull from
> the hi-entries
> in the incoming request. That hi-entry was not the one
> that was just
> added by the entity that built the request just received
> by the UAS.
> That hi-entry is tagged with whatever name we are going
> to tag it with
> BEFORE the request is forwarded (using the term forward
> per section 16.6
> of RFC 3261). That tag is added once the target set of
> potential
> candidates for the new request uri are determined in
> section 16.5 of
> 3261 (with "target set" being a 3261 term), just before
> the request is
> forwarded in section 16.6 to one of those targets. A
> new hi-entry
> (which will be the last hi-entry in the request received
> by the UAS) is
> added in section 16.6 of 3261 as the request is
> forwarded. At this
> point in time, the lost information is in the previous
> hi-entry when the
> outgoing request is sent. [/MB]
>
>
> What has been lost is the current target of the request:
>
> [MB] Right - at which point in my mind, it's no longer
> the current
> target ;) Maybe we call it "lost". [/MB]
>
>
>
> Current target
>
> The current target of an initial request for a dialog
> or standalone
> request is the name or address to which the request is
> targeted, i.e.
> either the initial target inserted in the Request-URI
> by the UAC that
> originates the request, or when a retarget occurred,
> the target
> provided in that retarget operation. Reroute and
> translation
> operations never change the current target.
>
>
> [MB] I don't think this definition fits what you want -
> i.e., if there
> is no retargeting, then none of the hi-entries are
> tagged - i.e., you
> won't have your concept of current. The way it works is
> that if no
> hi-entries are tagged, then you know that there was no
> retargeting, thus
> you know the request-uri has not been lost. [/MB]
>
>
> This defintion only makes sense when the following
> definitions are used:
>
> Name:
>
> A name is a moniker for an entity which refers to it
> in a way which
>
> reveals nothing about where it is in a network. In
> SIP, tel URI
>
> which doesn't represent the location of the entity is
> a name.
>
>
> Address:
>
> An address is an identifier for an entity which
> describes it by its
>
> location on the network. In SIP, the SIP URI itself
> is a form of
>
> address because the host part of the URI, the only
> mandatory part of
>
> the URI besides the scheme itself, indicates the
> location of a SIP
>
> server that can be used to handle the request.
>
> Route:
>
> Finally, a route is a sequence of SIP entities
> (including the UA
> itself!) which are
>
> traversed in order to forward a request to an address
> or name.
>
> Retarget (other term might be needed, as this is highly
> confusing):
>
> A Request-URI rewrite operation that changes the
> target identity of
> the request.
>
> Reroute (other term might be needed):
>
> A Request-URI rewrite operation that does not change
> the current
> target of the request, but determines the route/next
> hop taken to
> reach the target-identity.
>
> /Hans Erik
>
> Mary Barnes wrote:
> > 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:[email protected]]
> > Sent: Wednesday, March 11, 2009 4:40 PM
> > To: Barnes, Mary (RICH2:AR00)
> > Cc: Shida Schubert; [email protected]
> > 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:[email protected]]
> >> *Sent:* Wednesday, March 11, 2009 3:59 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
> >>
> >> 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
> <[email protected]
> >> <mailto:[email protected]>> 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: *[email protected]
> >>>
> > <mailto:[email protected]>
> >
> >>> *Date: *March 10, 2009 2:30:01 AM JST
> >>> *To: *[email protected]
> <mailto:[email protected]>
> >>> *Subject: **I-D
> >>>
> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt *
> >>> *Reply-To: *[email protected]
> >>> <mailto:[email protected]>
> >>>
> >>> 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-d
> >>> e
> >>> 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:
> >> <[email protected]<lt%[email protected]>
> <mailto:lt%[email protected]<lt%[email protected]>
> >
> >> <mailto:[email protected]>><BR><BR>
> >>
> >>> _______________________________________________
> >>> I-D-Announce mailing list
> >>> [email protected]
> <mailto:[email protected]>
> >>>
> 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 [email protected]
> >> <mailto:[email protected]> for
> questions on
> >> current
> >>
> > sip
> >
> >> Use [email protected] <mailto:[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