Terminology (was RE: Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

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]>
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]
		Date: March 10, 2009 2:30:01 AM JST
		To: [email protected]
		Subject: I-D
ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt 
		Reply-To: [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-deliv
ery-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:
&lt;[email protected]&gt;<BR><BR> 

		_______________________________________________
		I-D-Announce mailing list
		[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] 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