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:
Date: March 10, 2009 2:30:01 AM JST
Subject: I-D
ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
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-delivery-01.txtInternet-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><BR><BR>