Subject: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

From: Shida Schubert <[email-masked]>
Date: Wed, 11 Mar 2009 15:13:25 +0900

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-masked]
> Date: March 10, 2009 2:30:01 AM JST
> To: [email-masked]
> Subject: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
> Reply-To: [email-masked]
>
> 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.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;2009-3-9102756.I- 
[email-masked]&gt;<BR><BR>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> 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

---

From: Dean Willis <[email-masked]>
Date: Wed, 11 Mar 2009 01:37:30 -0500

On Mar 11, 2009, at 1:13 AM, Shida Schubert wrote:

>       RFC 4244 has attempted to clarify the terms and attempts to  
> use "forward"
>       a proxy is responsible for the domain and thus can use a  
> number of

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 11 Mar 2009 02:55:28 -0400

At the risk of opening up a topic we have already agreed on, but in the spirit of open communication... [how's that for an opener!?]

Are we absolutely sure we want to put this target-URI in the History-Info header?

I am not asking this because I think it's hard.  I am asking because I am not sure it will be used.  Several of us from this same WG are involved in the SIP-Forum's SIP-Connect profile, and when faced with either using this new History-Info mechanism for a target-uri delivery issue, vs. not, we chose not to.  And we were mostly the same people who liked the idea of putting it in History-Info in the IETF! (myself included)  But I am concerned that when given a reasonable opportunity to use a mechanism we ourselves promote when wearing a different hat, we chose not to use it in practice.  It doesn't bode well. :(

-hadriel
p.s. sorry Mary for raising this, but there isn't much email traffic anyway. :)

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shida Schubert
Sent: Wednesday, March 11, 2009 2:13 AM
To: [email-masked] List

 
 
Note, that the target-uri document still contains the normative text for the
History-Info header.
 
be integrated into RFC 4244 as it MUST work and be based on the normative
3. Added an additional requirement to capture the "target-uri" information.

::Issues::

      "target-identity" (someone didn't like that "identity" is also a SIP header)
 
      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:

	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

Content-Type: text/plain<BR>Content-ID: &lt;[email-masked]&gt;<BR><BR>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 11 Mar 2009 02:59:24 -0400

I vote no on 3, fwiw.  Keep it Simple.

-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 11 Mar 2009 09:36:26 +0100

I think that is a good question, because it is real world use that we would
like to serve. But at the same time when we want to progress this
requirement, it would be good to know what is an acceptable means to
transport the target-URI towards the UAS?

Would you reconsider using a distinct header for this?

/Hans Erik van Elburg

On Wed, Mar 11, 2009 at 7:55 AM, Hadriel Kaplan <[email-masked]>wrote:

>
> At the risk of opening up a topic we have already agreed on, but in the
> spirit of open communication... [how's that for an opener!?]
>
> I am not asking this because I think it's hard.  I am asking because I am
> not sure it will be used.  Several of us from this same WG are involved in
> the SIP-Forum's SIP-Connect profile, and when faced with either using this
> new History-Info mechanism for a target-uri delivery issue, vs. not, we
> chose not to.  And we were mostly the same people who liked the idea of
> putting it in History-Info in the IETF! (myself included)  But I am
> concerned that when given a reasonable opportunity to use a mechanism we
> ourselves promote when wearing a different hat, we chose not to use it in
> practice.  It doesn't bode well. :(
>
> -hadriel
> Content-Type: text/plain<BR>Content-ID: &lt;[email-masked]<[email-masked]>
> &gt;<BR><BR>
> Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft>directories:
> http://www.ietf.org/shadow.html
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 11 Mar 2009 09:58:48 +0100

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-masked]> wrote:

> *From: [email-masked]
> *Date: *March 10, 2009 2:30:01 AM JST
> *To: [email-masked]
> *Subject: **I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt *
> *Reply-To: [email-masked]
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 11 Mar 2009 11:32:23 +0000

Just to expand on what Hadriel says, the SIP Forum is addressing the case where a request is delivered by a SIP Service Provider to a SIP-PBX, the SIP-PBX having registered with the SIP-SP. The SIP-PBX needs to be in possession of the target, in order to route onwards correctly within the enterprise. If only the SIP-PBX's contact URI is available in the Request-URI, the SIP-PBX would have to look elsewhere for the target. In accordance with recent SIP WG agreements, this would be the History-Info header field, but that requires the present extension.

Advantages of putting the target in the Request-URI for this particular situation:
- This is where the SIP-PBX would normally expect to find the target when a request is received from elsewhere (e.g., another SIP-PBX within the enterprise), so it is reasonable also to expect it there when received from a SIP SP.
- SIPConnect 1.1 will not require History-Info for any other purpose, so it would make it a mandatory specification for SIPConnect 1.1 just in order to solve this particular problem, thereby raising the bar for SPs and SIP-PBXs wanting to comply with the spec.
- We would need to define procedures for what to do if History-Info is absent from a received request or if there is no entry marked as 'istarget'.
- SIPConnect 1.1 is due for completion in the next few weeks, and cannot wait the usual IETF cycle time for History-Info update to hit the RFC Editor's queue.
- If History-Info is used anyway (for its original purpose), the history revealed when a request comes from a SIP-SP via a SIP-PBX to another proxy and finally to a UAS would be unnecessarily complicated and therefore confusing, because the target would be replaced by a contact and would then appear again at the next hop.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hadriel Kaplan
> Sent: 11 March 2009 06:55
> To: Shida Schubert; [email-masked] List
> Cc: Mary Barnes
> Subject: Re: [Sip] Fwd: I-D 
> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
> 
> 
> At the risk of opening up a topic we have already agreed on, 
> but in the spirit of open communication... [how's that for an 
> opener!?]
> 
> I am not asking this because I think it's hard.  I am asking 
> because I am not sure it will be used.  Several of us from 
> this same WG are involved in the SIP-Forum's SIP-Connect 
> profile, and when faced with either using this new 
> History-Info mechanism for a target-uri delivery issue, vs. 
> not, we chose not to.  And we were mostly the same people who 
> liked the idea of putting it in History-Info in the IETF! 
> (myself included)  But I am concerned that when given a 
> reasonable opportunity to use a mechanism we ourselves 
> promote when wearing a different hat, we chose not to use it 
> in practice.  It doesn't bode well. :(
> 
> -hadriel
> Content-Type: text/plain<BR>Content-ID: 
> &lt;[email-masked]&gt;<BR><BR>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 11 Mar 2009 11:34:14 +0000

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Shida Schubert
	Sent: 11 March 2009 06:13
	To: [email-masked] List
	Cc: Mary Barnes
	Subject: [Sip] Fwd: I-D
ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

	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
	 
	Note, that the target-uri document still contains the normative
text for the
	History-Info header.
[JRE] I don't like this. I would prefer to have all the normative stuff
in one place, if RFC 4244 is being revised anyway.

John
	 
	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.

	::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:

		Subject: I-D

		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.

http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-deliv
ery-01.txt

		Below is the data which will enable a MIME compliant
mail reader
		implementation to automatically retrieve the ASCII
version of the
		Internet-Draft.

		Internet-Draft directories:

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 11 Mar 2009 13:26:30 +0100

Hi,

We had a looooong discussion about that (ua-loose-route vs Target), and I really hope we should not go back there now.

I think we should focus on whether we want to have this in H-I, as currently proposed, or as a separate header.

Regards,

Christer

> Behalf Of Elwell, John
> Sent: 11. maaliskuuta 2009 13:32
> To: Hadriel Kaplan; Shida Schubert; [email-masked]
> Cc: Mary Barnes
> Just to expand on what Hadriel says, the SIP Forum is 
> addressing the case where a request is delivered by a SIP 
> Service Provider to a SIP-PBX, the SIP-PBX having registered 
> with the SIP-SP. The SIP-PBX needs to be in possession of the 
> target, in order to route onwards correctly within the 
> enterprise. If only the SIP-PBX's contact URI is available in 
> the Request-URI, the SIP-PBX would have to look elsewhere for 
> the target. In accordance with recent SIP WG agreements, this 
> would be the History-Info header field, but that requires the 
> present extension.
> 
> - This is where the SIP-PBX would normally expect to find the 
> target when a request is received from elsewhere (e.g., 
> another SIP-PBX within the enterprise), so it is reasonable 
> also to expect it there when received from a SIP SP.
> - SIPConnect 1.1 will not require History-Info for any other 
> purpose, so it would make it a mandatory specification for 
> SIPConnect 1.1 just in order to solve this particular 
> problem, thereby raising the bar for SPs and SIP-PBXs wanting 
> to comply with the spec.
> - We would need to define procedures for what to do if 
> History-Info is absent from a received request or if there is 
> no entry marked as 'istarget'.
> - SIPConnect 1.1 is due for completion in the next few weeks, 
> and cannot wait the usual IETF cycle time for History-Info 
> update to hit the RFC Editor's queue.
> - If History-Info is used anyway (for its original purpose), 
> the history revealed when a request comes from a SIP-SP via a 
> SIP-PBX to another proxy and finally to a UAS would be 
> unnecessarily complicated and therefore confusing, because 
> the target would be replaced by a contact and would then 
> appear again at the next hop.
> 
> John
>  
> 
> Behalf Of 
> > Hadriel Kaplan
> > At the risk of opening up a topic we have already agreed on, but in 
> > the spirit of open communication... [how's that for an opener!?]
> > 
> > I am not asking this because I think it's hard.  I am 
> asking because I 
> > am not sure it will be used.  Several of us from this same WG are 
> > involved in the SIP-Forum's SIP-Connect profile, and when 
> faced with 
> > either using this new History-Info mechanism for a 
> target-uri delivery 
> > issue, vs.
> > not, we chose not to.  And we were mostly the same people who liked 
> > the idea of putting it in History-Info in the IETF!
> > (myself included)  But I am concerned that when given a reasonable 
> > opportunity to use a mechanism we ourselves promote when wearing a 
> > different hat, we chose not to use it in practice.  It doesn't bode 
> > well. :(
> > 
> > -hadriel
> > p.s. sorry Mary for raising this, but there isn't much 
> email traffic 
> > anyway. :)
> > 
> Behalf Of 
> > Shida Schubert
> > 1. Added use-case for toll-free number back 2. Added definition of 
> > "retarget" operation.
> > 4. Added a text discussing the difference to P-Called-Party-Id 5. 
> > Changed parameter name from "target" to "istarget"
> >  
> > for the History-Info header.
> >  
> > 1. Incorporated the normative aspects of the target-uri 
> document into 
> > the existing normative text in RFC 4244 - the functionality is 
> > 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.
> >       One reason this is so difficult relates to the 
> problem statement 
> > in target-uri in that
> >       (target) Request-URI is selected.  Another issue is 
> that some of 
> > the terminology in
> >       the outgoing request is built and "forwarded" to the 
> next hop at 
> > which
> proposed 
> separate 
> > on the two documents prior to IETF-74.
> >  
> > Regards,
> > Shida and Mary.
> > 
> > 
> > 
> > Begin forwarded message:
> > Internet-Draft directories: http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 11 Mar 2009 11:26:48 -0500

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:[email-masked]] 
Sent: Wednesday, March 11, 2009 1:38 AM
To: Shida Schubert
Cc: [email-masked] List; Barnes, Mary (RICH2:AR00)
Subject: Re: [Sip] Fwd: I-D

On Mar 11, 2009, at 1:13 AM, Shida Schubert wrote:

>
>       One reason this is so difficult relates to the problem statement

>       (target) Request-URI is selected.  Another issue is that some of

>       the outgoing request is built and "forwarded" to the next hop at

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

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 11 Mar 2009 11:39:06 -0500

Yeah, we can define a new header and just ignore the use of a basic SIP building block that the WG spent 2.5 years  (note this doesn't include the 2+ years spent on the doc as an individual and as a SIPPING WG document ;)  And, while we're at it, let's just go ahead and obsolete 4244 altogether and standardize diversion (something the WG rejected almost a decade ago). That will make one vendor and a handful of SPs very happy and those of us that have implemented the specs can ripout some code after while when we have some spare change to pay folks to do so (and of course, this is after the folks that have not implemented diversion actually implement it - there are actually some of those out there). 

As an aside, this is another fine example as to why we don't seem to make great progress or produce specs that are deemed useful - we agree on a way forward and then change our minds later (sometimes for good reasons and sometimes because a shortcut seems easier or it's just arbitrary based on the phase of the moon it seems).  

Mary. 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Wednesday, March 11, 2009 1:55 AM
To: Shida Schubert; [email-masked] List
Cc: Barnes, Mary (RICH2:AR00)
Subject: RE: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

-hadriel

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.

::Issues::

 

 

Regards,
Shida and Mary.

Begin forwarded message:

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 11 Mar 2009 12:44:37 -0400

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Wednesday, March 11, 2009 8:27 AM
> To: Elwell, John; Hadriel Kaplan; Shida Schubert; [email-masked]
> 
> We had a looooong discussion about that (ua-loose-route vs Target), and I
> really hope we should not go back there now.

I wouldn't have, were it not for the Sip-Forum experience.  If a bunch of people who spent time on the topic don't even want to use the mechanism, what hopes do we have that it will succeed in the marketplace?  

And don't get me wrong - it could have been in a "Target" header too and we wouldn't have used that either, I think.  Although part of the reason is because we know IP-PBX's actually support Jonathan's original ua-loose-route concept (just without the Route header part), whereas I'm not so sure what legacy endpoints will do with an AoR-req-uri; nor whether the req-uri would ever survive end-to-end in Peering cases.  

So I was in favor of doing a separate Header because it was "safer", in terms of not breaking interoperability - but it's less chance for actually getting used, which in a way does break something too (customer expectations).  Ugh.  Screwed either way.

-hadriel

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 11 Mar 2009 12:02:56 -0500

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-masked]] 
Sent: Wednesday, March 11, 2009 3:59 AM
To: Shida Schubert
Cc: [email-masked] 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.

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-masked]>
wrote:

	 

	 

	::Issues::

	 

	 

	Regards,
	Shida and Mary.

	Begin forwarded message:

		

		

	_______________________________________________
	Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
	This list is for NEW development of the core SIP Protocol
	Use [email-masked] for questions on current
sip
	Use [email-masked] for new developments on the application of
sip

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 11 Mar 2009 12:06:41 -0500

BTW - in the end, I really don't care what we call the tag - the term
just needs to be precisely defined and I'd rather it not be based on a
term in RFC 3261 that is already overloaded and doesn't precisely match
the semantics for the tag in 4244bis.

From: Barnes, Mary (RICH2:AR00) 
Sent: Wednesday, March 11, 2009 12:03 PM
To: 'Hans Erik van Elburg'; Shida Schubert
Cc: [email-masked] List
Subject: Terminology (was RE: [Sip] Fwd: I-D
ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

Mary. 

/Hans Erik van Elburg

	 

	 

	::Issues::

	 

	 

	Regards,
	Shida and Mary.

	Begin forwarded message:

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 11 Mar 2009 13:04:48 -0400

I don't actually have much stake in Diversion - you know it wasn't us who implemented it first, and it's a softswitch/PBX thing not SBC thing anyway - I just hate having two ways of doing the same thing, or having to convert between the (multiple) vendors that do one or the other.  And before you throw stones at me for it, you can look into your own product line and find that there are products that only do Diversion and not Hist-Info.  In fact several vendors have a mixture of both across product lines, afaict.

But anyway I'm not debating the merits of History-Info vs. Diversion.  That time has passed, and we will just have to live with both for a while, and hopefully someday Hist-Info will win.  I will be happy to convert between it and Diversion for now, just so it can be un-converted on the other side of the link, so that a piece of wire can claim to be standards-compliant. ;) 

I'm not even arguing for a new header.  
I'm just saying something ain't right when we don't even want to use it in practice.  If we can't eat our own dog food, there's something wrong with the food.

-hadriel

> From: Mary Barnes [mailto:[email-masked]]
> Sent: Wednesday, March 11, 2009 12:39 PM
> Yeah, we can define a new header and just ignore the use of a basic SIP
> building block that the WG spent 2.5 years  (note this doesn't include the
> 2+ years spent on the doc as an individual and as a SIPPING WG document ;)
> And, while we're at it, let's just go ahead and obsolete 4244 altogether
> and standardize diversion (something the WG rejected almost a decade ago).
> That will make one vendor and a handful of SPs very happy and those of us
> that have implemented the specs can ripout some code after while when we
> have some spare change to pay folks to do so (and of course, this is after
> the folks that have not implemented diversion actually implement it -
> there are actually some of those out there).
> 
> As an aside, this is another fine example as to why we don't seem to make
> great progress or produce specs that are deemed useful - we agree on a way
> forward and then change our minds later (sometimes for good reasons and
> sometimes because a shortcut seems easier or it's just arbitrary based on
> the phase of the moon it seems).
> 
> Mary.

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 11 Mar 2009 12:20:20 -0500

Well, we do advise the products to implement History-Info and the one
that I was responsible for in the past does implement all three
(including the remote-party-id solution).  

On your last point, it's not clear to me the reason why folks haven't
implemented it, other than that it's just in the pile of stuff that they
haven't implemented. And, it's not all the members of SIP Forum that
haven't implemented it (perhaps the subset that are currently
contributing to the SIP Connect spec).  There is a handful of vendors
that interop with one of our products (that I know has implemented HI)
that do implement it, as well. So, I don't think it's fair to say across
the industry it has not been implemented.  

Now, I can see folks not wanting to implement it from the perspective
that there are already a number of core interop issues per your interop
document, thus there's really no point in adding something like HI when
the basics are broken. But, that's a broader problem and kinda takes us
to Dean's tricycle analogy on the RAI list. 

Mary. 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Wednesday, March 11, 2009 12:05 PM
To: Barnes, Mary (RICH2:AR00); Shida Schubert; [email-masked]
Subject: RE: [Sip] Fwd: I-D

I don't actually have much stake in Diversion - you know it wasn't us
who implemented it first, and it's a softswitch/PBX thing not SBC thing
anyway - I just hate having two ways of doing the same thing, or having
to convert between the (multiple) vendors that do one or the other.  And
before you throw stones at me for it, you can look into your own product
line and find that there are products that only do Diversion and not
Hist-Info.  In fact several vendors have a mixture of both across
product lines, afaict.

But anyway I'm not debating the merits of History-Info vs. Diversion.
That time has passed, and we will just have to live with both for a
while, and hopefully someday Hist-Info will win.  I will be happy to
convert between it and Diversion for now, just so it can be un-converted
on the other side of the link, so that a piece of wire can claim to be
standards-compliant. ;) 

I'm not even arguing for a new header.  
I'm just saying something ain't right when we don't even want to use it
in practice.  If we can't eat our own dog food, there's something wrong
with the food.

-hadriel

> Yeah, we can define a new header and just ignore the use of a basic 
> SIP building block that the WG spent 2.5 years  (note this doesn't 
> include the
> 2+ years spent on the doc as an individual and as a SIPPING WG 
> 2+ document ;)
> And, while we're at it, let's just go ahead and obsolete 4244 
> altogether and standardize diversion (something the WG rejected almost
a decade ago).
> That will make one vendor and a handful of SPs very happy and those of

> us that have implemented the specs can ripout some code after while 
> when we have some spare change to pay folks to do so (and of course, 
> this is after the folks that have not implemented diversion actually 
> implement it - there are actually some of those out there).
> 
> As an aside, this is another fine example as to why we don't seem to 
> make great progress or produce specs that are deemed useful - we agree

> on a way forward and then change our minds later (sometimes for good 
> reasons and sometimes because a shortcut seems easier or it's just 
> arbitrary based on the phase of the moon it seems).
> 
> Mary.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 11 Mar 2009 13:56:40 -0400

I never said across the industry it has not been implemented - I know it has by some because we have to convert it for some.  I think the reason it hasn't gained dominance is because Diversion was done first by many, and if it ain't broke they have no reason to fix it compared with other priorities; or it just takes them years to do such things and get it deployed.  

-hadriel

> Sent: Wednesday, March 11, 2009 1:20 PM
>

---

From: Theo Zourzouvillys <[email-masked]>
Date: Wed, 11 Mar 2009 18:20:02 +0000

On Wed, Mar 11, 2009 at 5:04 PM, Hadriel Kaplan <[email-masked]> wrote:

> If we can't eat our own dog food, there's something wrong with the food.

or you've not yet worked out how to open the tin.

i am strongly in support of this mechanism.

 ~ Theo

---

From: Theo Zourzouvillys <[email-masked]>
Date: Wed, 11 Mar 2009 20:07:55 +0000

> i am strongly in support of this mechanism.

sorry, too may lists, threads, and offlist discussions - and not enough sleep.

i'm not trying to suggest that we should be working on mechanisms for
opening tins (although will happily entertain any new mechanisms -
there is currently only one practical way i am aware of opening tins,
which means it doesn't meet SIPs minimum quota for "ways to do
thing"); so let me reword my previous message so it makes sense to
anyone other then me:

  i am strongly in favour of putting the target URI in HI.

:)

 ~ Theo

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 11 Mar 2009 16:50:39 -0400

> From: Theo Zourzouvillys [mailto:[email-masked]]
> Sent: Wednesday, March 11, 2009 2:20 PM
> 

I think most everyone in the SIP Forum knows how the mechanism could work using HI.  The question was if we wanted to solve the issue using HI for the SIP-Connect profile.  I think the rationale for "no" was the feeling we had on whether PBX's would actually support HI anytime soon, or whether in practice we would actually be doing something different in deployment to actually make calls work.  (though I can't really speak for others - I could be totally wrong on that, this was just the sense I got)

Personally, I look at it from a motivation perspective: who has the motivation to change to make something work?  In the SIP-Connect case, the Service Provider is the one selling the SIP-Trunk service, so to win the deal and satisfy customers they've got more of the motivation/burden to make it work.  The SP's also have a large motivation to support as many IP-PBX vendors as possible.  Any changes we mandate of IP-PBX vendors will reduce the pool of them that are "SIP-Connect compliant", which is not good.  Especially when what we're proposing basically works *now* in SIP-Trunk deployments - i.e., there's running code.  It doesn't quite work that way today within the SP's domain on the wire, but as I said they have the motivation (and the ability) to change their side.

-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 11 Mar 2009 22:40:04 +0100

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:
> 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-masked]]
> *Sent:* Wednesday, March 11, 2009 3:59 AM
> *To:* Shida Schubert
> *Cc:* [email-masked] List; Barnes, Mary (RICH2:AR00)
> *Subject:* Re: [Sip] Fwd: I-D 
> 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.
>
> embellish them with a tag that just represents there meaning for 
> example "istarget" or "hop". For the following reasons:
> 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-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>>     *From: [email-masked] <mailto:[email-masked]>
>>     *To: [email-masked] <mailto:[email-masked]>
>>     *Subject: **I-D
>>     ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt *
>>     <mailto:[email-masked]>
>>
>>     Title
>>     : Delivery of Request-URI Targets to User Agents
>>     Author(s)
>>     : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. Schubert
>>     Pages
>>     : 16
>>     Date
>>     : 2009-3-9
>     &lt;[email-masked]
>     <mailto:[email-masked]>&gt;<BR><BR>
>>     [email-masked] <mailto:[email-masked]>
>     Use [email-masked]
>     <mailto:[email-masked]> for questions on current sip
>     Use [email-masked] <mailto:[email-masked]> for new
>     developments on the application of sip
>
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 11 Mar 2009 16:50:20 -0500

> I think most everyone in the SIP Forum knows how the mechanism could work 
> using HI.  The question was if we wanted to solve the issue using HI for 
> the SIP-Connect profile.  I think the rationale for "no" was the feeling 
> we had on whether PBX's would actually support HI anytime soon, or whether 
> in practice we would actually be doing something different in deployment 
> to actually make calls work.  (though I can't really speak for others - I 
> could be totally wrong on that, this was just the sense I got)
>

Speaking only for myself, I thought that the obstacle for SIPconnect was 
that there was already a history-info-bis effort underway - we just weren't 
excited about requiring support for a mechanism that was being revised. It 
wasn't clear to me that we would be equally unexcited if 4244bis was 
approved for publication.

But as Hadriel says, I could also be totally wrong about that. And other 
people don't have to be shy about explaining things to me.

Thanks,

Spencer

> Personally, I look at it from a motivation perspective: who has the 
> motivation to change to make something work?  In the SIP-Connect case, the 
> Service Provider is the one selling the SIP-Trunk service, so to win the 
> deal and satisfy customers they've got more of the motivation/burden to 
> make it work.  The SP's also have a large motivation to support as many 
> IP-PBX vendors as possible.  Any changes we mandate of IP-PBX vendors will 
> reduce the pool of them that are "SIP-Connect compliant", which is not 
> good.  Especially when what we're proposing basically works *now* in 
> SIP-Trunk deployments - i.e., there's running code.  It doesn't quite work 
> that way today within the SP's domain on the wire, but as I said they have 
> the motivation (and the ability) to change their side.
>
> -hadriel
>

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 11 Mar 2009 17:30:03 -0500

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-masked]] 
Sent: Wednesday, March 11, 2009 4:40 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Shida Schubert; [email-masked]
Subject: Re: Terminology (was RE: [Sip] Fwd: I-D

/Hans Erik

Mary Barnes wrote:
> 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.

comments 
document
is 
solution 
parameter.
progress
inappropriate 
called 
potentially 
uses
below)
new
mapping 
>>     *From: [email-masked]
<mailto:[email-masked]>
Internet-Drafts 
responsible
delivered to

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 12 Mar 2009 00:42:13 +0100

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.

What has been lost is the current target of the request:

      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.

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:
>>     We had some very long offline exchanges as to the best way forward
>>     
> and
>   
>>           a consensus on what name is appropriate.  Other suggestions
>>     
> have
>   
>>           included the following:
>>>       contact URI of an agent representing that user or resource.  In
>>>       
> the
>   
>>>       an extension to the History-Info header field which allows it
>>>       
> to be
>   
>>     <mailto:[email-masked]> for questions on current
>>     
> sip
>

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 11 Mar 2009 20:33:48 -0500

Responses below [MB].

-----Original Message-----
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Wednesday, March 11, 2009 6:42 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Shida Schubert; [email-masked]
Subject: Re: Terminology (was RE: [Sip] Fwd: I-D

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

[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]

Name:

Address:

Route:

/Hans Erik

Mary Barnes wrote:
> 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

> I honestly don't care what we call the tag, as long as we're clear 
> about the functionality.
>
> Mary. 
>
> information then it still can be considered application agnostic as 
> any application can use this information as it likes.
>

>> any
>> ---------------------------------------------------------------------
>> -
>> --

>> forward
a
>>           mechanism to select the new target for the request - e.g.,
a
>>          The general consensus of the authors of the two documents
was
configured
>>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-d
>>> e
>>> livery-01.txt
>>>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 12 Mar 2009 09:34:34 +0100

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-masked]> wrote:

> >>     &lt;[email-masked] <[email-masked]>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 12 Mar 2009 11:08:57 +0000

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-masked] [mailto:[email-masked]] On
Behalf Of Hans Erik van Elburg
	Sent: 12 March 2009 08:35
	To: Mary Barnes
	Cc: [email-masked]
	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.

	   "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".

	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-masked]> wrote:

		Responses below [MB].

		-----Original Message-----
		From: Hans Erik van Elburg
[mailto:[email-masked]]

		
		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]

		[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

		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.

		   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

		
		
		>> they come about "retarget"/"mapped conficuration"
etc. It is better
		
		>> header. Contrary to what the draft says. So some work
is needed
		still.
		
		a
		a
		was
		>>          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
<mailto:[email-masked]>
		>>>     : J. Rosenberg, H. van Elburg, C. Holmberg, F.
Audet, S.
		Schubert
		>>>     Pages
		>>>     : 16
		>>>     Date
		>>>     : 2009-3-9
		>>>
		>>>     When a Session Initiation Protocol (SIP) proxy
receives a
		request
		configured
		>>>       contact URI of an agent representing that user
or resource.
		>>> In
		>>>       the user agent.  This document describes these
use cases and
		>>>     defines
		>>>     implementation to automatically retrieve the
ASCII version of
		the
		>>     &lt;[email-masked]
<mailto:[email-masked]> 
		>>     <mailto:[email-masked]>&gt;<BR><BR>
<mailto:[email-masked]>
		>>     Sip mailing list
https://www.ietf.org/mailman/listinfo/sip
		>>     <mailto:[email-masked]> for
questions on
		>> current

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 12 Mar 2009 13:56:35 +0100

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-masked]>wrote:

>                >>     &lt;[email-masked]<[email-masked]>
> <mailto:[email-masked]<[email-masked]>
> >

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 12 Mar 2009 13:30:43 +0000

Hans Erik,
 
The way I interpreted the 01 draft, you would not get the freephone
number anyway. If that is a requirement, then I accept my suggestion
won't suffice.
 
John

	From: Hans Erik van Elburg [mailto:[email-masked]] 
	Sent: 12 March 2009 12:57
	To: Elwell, John
	Cc: [email-masked]
	Subject: Re: [Sip] Terminology (was RE: Fwd:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

	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.

	
	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-masked]> 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-masked]
[mailto:[email-masked]] On
		Behalf Of Hans Erik van Elburg
		       Sent: 12 March 2009 08:35
		       To: Mary Barnes
		       Cc: [email-masked]
		       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.

		          "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

		               Responses below [MB].

		               -----Original Message-----
		
		               Sent: Wednesday, March 11, 2009 6:42 PM
		               To: Barnes, Mary (RICH2:AR00)
		               Cc: Shida Schubert; [email-masked]
		               Subject: Re: Terminology (was RE: [Sip]
Fwd: I-D

		
		               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.

		                  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
		
		               > I honestly don't care what we call the
tag, as long as
		we're clear
		               >
		               > 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
		               >  From SIP perspective all the
Request-URI rewrites
		look the same, that
		
		               >> 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
	
		               >>
		               >> One of the problems that made the
discussion quite
		tedious is the
		               >> complete inversed meaning of the terms
"retarget" and
		"reroute"
		               >> Conclusion was that the terminology
need to be
		properly defined and
		               >> On 3. I have strong concerns when we
start tagging
		the URI as to how
		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
		               >> 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
		
		is needed
		               still.
		               >>
		               >> /Hans Erik van Elburg
		               >>
		               >>
		               >> On Wed, Mar 11, 2009 at 7:13 AM, Shida
Schubert
		<[email-masked]
		               >>     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
		               >>     The following summarizes the
changes made to the
		target-uri
		               >>     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
		               >>     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
		               >>     3. Added an additional requirement
to capture the
		"target-uri"
		               >>     information.
		               >>     4. Fixed an error in the RFC 4244
ABNF and added
		"retarget"
		               >>     We had some very long offline
exchanges as to the
		best way
		               >>        1. Should we remove the
normative text from
		target-uri and
		               >>            4244bis along with the
target-uri document
		to meet the
		               >>           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
		               >>           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
		               >>           "reg-uri"  (can be paired
with "mapped-uri"
		for item 3
		               >>           One reason this is so
difficult relates to
		the problem
		               >>           RFC 3261 doesn't
differentiate the
		mechanism by which the
		               >>           (target) Request-URI is
selected.  Another
		issue is that
		               >>           RFC 3261 is overloaded -
e.g., "forwarding"
		refers both to
		               a
		               >>           which does not have
responsibility for the
		domain of the
		               >>           in the incoming request,
thus the proxy
		just "forwards" the
		               >>           the next hop AND
"forwarding" is used to
		describe the
		               >>           the outgoing request is
built and
		"forwarded" to the next
		               >>           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
		               >>           we differentiate the
hi-entries even more
		by defining
		               >>          for registered and
configured/mapped
		contacts.
		               >>          Currently when the R-URI is
translated to a
		URI which is
		               >>          from location service
lookup(registered by
		UA) or from
		               >>          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
		naming contest. In
		isn't too overloaded
		               >>     We would appreciate WG feedback on
these issues
		and any other
		               >>>     A New Internet-Draft is available
from the
		on-line
		Audet, S.
		               Schubert
		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
		or resource.
		               >>> In
		               >>>
		               > the
		               >
		               >>>       process, the original URI is
removed from the
		request.
		               >>>      Numerous use
		               >>>       cases have arisen which require
this
		information to be
		use cases and
		               >>>       an extension to the
History-Info header field
		which allows it
	
		               >>>     Internet-Drafts are also
available by anonymous
		FTP at:
		               >>>
		               >>>     Below is the data which will
enable a MIME
		compliant mail reader
		ASCII version of
		               the
		
		<mailto:[email-masked]
<mailto:[email-masked]> >
		
		               >>>     or
		               >>     This list is for NEW development
of the core SIP
		Protocol
		               >>     Use [email-masked]
<mailto:[email-masked]>
		for new

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Mar 2009 08:46:00 -0500

Yeah, we did looked at that approach, BUT there are two problems:
1) It doesn't take into account the case where it's just a proxy hop to
a new domain  - i.e., those also won't be tagged. We also considered
just flagging those proxy hops, but then you still get into trouble with
the last entry as that isn't what you want - you typically want the
previous entry, which takes us to the next problem.  
2) You are then back to assuming that the one you want is one back from
the current hi-entry. I thought the whole point was to have it obviously
tagged. 

I am struggling with why tagging the ones, that we truly know are lost,
at the point we know they're lost won't work?  Isn't that the
information that is really desired?  

I think the 'iscontact' tag is a fine name - I just think we need to use
that in the manner currently specified in 4244bis for the "retarget"
flag. 

As far as Hans Erik's point about not discussing implementation, I don't
think not discussing implementation is at all helpful. I think the
problem statement is already fairly well laid out in the target-uri
draft. And, if you plan on using History-Info as the solution, we MUST
understand how it works now and we MUST understand how the proposed
solution works within the existing History-Info processing structure -
it's the just the same as we do with any new SIP header. And, indeed it
was the same thing that was done for the History-Info header to make
sure it was consistent with RFC 3261. The terminology is an issue and I
just think it takes precise wording ONCE we all understand the
implementation - it's got to be compatible with 3261 processing (now, we
can suggest some clarifications to that text and again, the definitions
that are currently in 4244bis are an attempt to do so).

That all said, we can certainly name the tag now and the 'iscontact'
does work for me.

Mary. 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, March 12, 2009 6:09 AM
To: Hans Erik van Elburg; Barnes, Mary (RICH2:AR00)
Cc: [email-masked]
Subject: RE: [Sip] Terminology (was RE: Fwd:

John

	

	   "To avoid confusion, we
	
	   "hop".

	
	/Hans Erik van Elburg

		Responses below [MB].

		-----Original Message-----

		

		

		     Current target

		
		Name:

		

		Address:

		

		
		Route:

		

		
		
		/Hans Erik

		
		
etc. It is better
		
is needed
		still.
		
		a
		a
		was
naming contest. In
isn't too overloaded
Audet, S.
		Schubert
receives a
		request
		configured
or resource.
use cases and
ASCII version of
		the
questions on

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 12 Mar 2009 13:44:23 +0000

(Old messages stripped to prevent blocking)

Hans Erik,

John

	

	

	BR,
	/Hans Erik van Elburg

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 12 Mar 2009 14:49:44 +0100

Hi,
 
IF we would remove that requierment, and ONLY care about the case when
the R-URI is replaced with the CONTACT, I don't think we need to do
anything. I believe P-Called-Party-ID already solves that.
 
Regards,
 
Christer

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
	Sent: 12. maaliskuuta 2009 15:31
	To: Hans Erik van Elburg
	Cc: [email-masked]
	Subject: Re: [Sip] Terminology (was RE: Fwd:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

	Hans Erik,
	 
	The way I interpreted the 01 draft, you would not get the
freephone number anyway. If that is a requirement, then I accept my
suggestion won't suffice.
	 
	John

		
		A calls Bfreephonenumber routed the B (AOR) routed to
B's contact.

		So what we like to see that B UA receives is something
like
		    H-I:  Bfreephone; "istarget",\
		        B,\
		        contact-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

			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

			       Subject: Re: [Sip] Terminology (was RE:
Fwd:

			       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.

			          "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".

			       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-masked]> wrote:

			               Responses below [MB].

			               -----Original Message-----
			
			               Sent: Wednesday, March 11, 2009
6:42 PM
			               To: Barnes, Mary (RICH2:AR00)
			               Cc: Shida Schubert; [email-masked]
			               Subject: Re: Terminology (was RE:
[Sip] Fwd: I-D

			
			               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
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
			
			               > I honestly don't care what we
call the tag, as long as
			we're clear
			               >
			               > 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
Request-URI rewrites
			look the same, that
			
			               >> And, I think the big issue
with the terminology is
			that 4244bis is
			               >> application agnostic, so it is
tagging what happens
			to the URIs
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
hopefully make this
			topic easier to
	
			               >>
			               >> One of the problems that made
the discussion quite
			tedious is the
			               >> complete inversed meaning of
the terms "retarget" and
			"reroute"
			               >> Conclusion was that the
terminology need to be
			properly defined and
			               >> On 3. I have strong concerns
when we start tagging
			the URI as to how
			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
			
			is needed
			               still.
			               >>
			               >> /Hans Erik van Elburg
			               >>
			               >>
			               >> On Wed, Mar 11, 2009 at 7:13
AM, Shida Schubert
			<[email-masked]
			               >>     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
			               >>     The following summarizes
the changes made to the
			target-uri
			               >>     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
			               >>     In addition, Mary (with
Francois as co-author)
			has submitted a
			               >>     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
			               >>     described in the
target-uri document.  It's
			important that the
			               >>     be integrated into RFC
4244 as it MUST work and
			be based on the
			               >>     2.  Added the use cases
from target-uri the the
			summary
			               >>     3. Added an additional
requirement to capture the
			"target-uri"
			               >>     4. Fixed an error in the
RFC 4244 ABNF and added
			"retarget"
			               >>     We had some very long
offline exchanges as to the
			best way
normative text from
			target-uri and
			               >>            4244bis along with
the target-uri document
			to meet the
			               >>        2. Name of the
parameter.
parameter "target" was
			said
			               >>           because
voicemail-uri spec already defines
			a parameter
			               >>           "target" which also
can be found in
			hi-entry, thus
			               >>           Currently the
target-uri draft uses
			"istarget" and 4244bis
			               >>           a consensus on what
name is appropriate.
			Other suggestions
			               >>           included the
following:
			               >>           "target-identity"
(someone didn't like that
			"identity" is
			               >>           "reg-uri"  (can be
paired with "mapped-uri"
			for item 3
			               >>           One reason this is
so difficult relates to
			the problem
differentiate the
			mechanism by which the
			               >>           (target) Request-URI
is selected.  Another
			issue is that
			               >>           RFC 3261 is
overloaded - e.g., "forwarding"
			refers both to
			               a
responsibility for the
			domain of the
			               >>           in the incoming
request, thus the proxy
			just "forwards" the
"forwarding" is used to
			describe the
			               >>           the outgoing request
is built and
			"forwarded" to the next
			               >>           point the proxy does
not know how the new
			request-uri was
			               >>           RFC 4244 has
attempted to clarify the terms
			and attempts to
			               >>           in the context of
the former situation and
			"retarget" for
			               >>           a proxy is
responsible for the domain and
			thus can use a
			               >>           mechanism to select
the new target for the
			request - e.g.,
			               a
			               >>           configured data,
etc.
			               >>      3.  Related to the last
point in item 2 above,
			it has been
hi-entries even more
			by defining
configured/mapped
			contacts.
			               >>          Currently when the
R-URI is translated to a
			URI which is
lookup(registered by
			UA) or from
			               >>          The general consensus
of the authors of the
			two documents
			               was
			               >>          be useful for some
services to have the
			hi-entries tagged
			naming contest. In
			isn't too overloaded
			               >>     We would appreciate WG
feedback on these issues
			and any other
	
			               >>>     A New Internet-Draft is
available from the
			on-line
			Audet, S.
			               Schubert
			receives a
			               request
			               >>>       targeted at a URI
identifying a user or
			resource it is
			               >>>       for, the proxy
translates the URI to a
			registered or
			               configured
			or resource.
			               >>>       process, the original
URI is removed from the
			request.
			               >>>       cases have arisen which
require this
			information to be
			use cases and
	
available by anonymous
			FTP at:
			               >>>     Below is the data which
will enable a MIME
			compliant mail reader
			ASCII version of
			               the

	
			               >>     This list is for NEW
development of the core SIP
			Protocol

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 12 Mar 2009 15:06:05 +0100

Hi,

Regards,
 
Christer

	Hans Erik,

	John

		

		

		BR,
		/Hans Erik van Elburg

			
			John

	

			
			
			          "To avoid confusion, we
			
			          "hop".

			
			       /Hans Erik van Elburg

			               Responses below [MB].

			               -----Original Message-----

			

			

			                    Current target
			
			                 The current target of an

			               [MB] I don't think this

			               Name:

			

			               Address:

			

			
			               Route:
			
			                 Finally, a route is a
sequence of SIP entities
			(including the UA
			               itself!) which are

			
			                  A Request-URI rewrite

			                  A Request-URI rewrite
			
			               /Hans Erik

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 12 Mar 2009 15:54:52 +0100

I'm fine with discussing implementation if everyone is meaning the same if
they use the same words.

As  to the "retarget" term such does not seem to be the case.

/Hans Erik van Elburg

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 12 Mar 2009 08:11:10 -0700

Does p-called-header include URI parameters?

On Mar 12, 2009, at 7:07, "Christer Holmberg" <[email-masked] 

>
> Hi,
>
> IF we would remove that requierment, and ONLY care about the case  
> when the R-URI is replaced with the CONTACT, I don't think we need  
> to do anything. I believe P-Called-Party-ID already solves that.
>
> Regards,
>
> Christer
>
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of Elwell, John
> Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft- 
> rosenberg-sip-target-uri-delivery-01.txt
>
> Hans Erik,
>
> Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft- 
> rosenberg-sip-target-uri-delivery-01.txt
>
> 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.
>
> The target-uri draft is interested in obtaining: Bfreephonenumber as  
> that is what A used to reach B.
>
> PBX's would interested in that to deliver to the correct user. We  
> could distinguish them like:
> On Thu, Mar 12, 2009 at 12:08 PM, Elwell, John <[email-masked] 
> > wrote:

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Mar 2009 10:19:51 -0500

When I use "retarget" I am using the definition that I put into 4244bis.
So, if you could ignore the tag or change it to 'iscontact' or whatever,
what would you change in that definition? Also, consider that if you
were to change everyplace that I use
"retarget"/"retargeted"/"retargeting" in 4244bis with 'iscontact' the
text would not make sense. So, even if we change the name of the tag, we
still need to understand the concept or define another term that means
that the request-uri in the incoming request (which should be the same
as the last hi-entry in the request) is being chnaged due to service
lookup, configuration, blah, blah, blah and that to meet the
requirements in the target-uri document, we want to tag this entry so
that this request-uri is not "lost" - i.e., this is the one the services
identified in the target-uri document care about. 
 
So, right now, here's what's in 4244bis:
 
   The term "retarget" is used in this document to refer to the process
   of a Proxy Server/User Agent Client (UAC) changing a Uniform Resource
   Identifier (URI) in a request based on a lookup in a location service
   and thus changing the target of the request.
 
We have previously discussed that we do need to expand the "based on a
lookup in a location service" to include configuration, etc., so let's
not debate that. 
 
But, what explicitly is the concern with that definition?
 
Mary. 

From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Thursday, March 12, 2009 9:55 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Elwell, John; [email-masked]
Subject: Re: [Sip] Terminology (was RE: Fwd:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

I'm fine with discussing implementation if everyone is meaning the same
if they use the same words.

/Hans Erik van Elburg

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Mar 2009 10:56:58 -0500

And, just to clarify the phrase 
"...changing a Uniform Resource Identifier (URI) in a request..." should
perhaps be worded more specifically as:
" ...changing the Request-URI in a SIP request..."

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Barnes, Mary (RICH2:AR00)
Sent: Thursday, March 12, 2009 10:20 AM
To: Hans Erik van Elburg
Cc: [email-masked]; Elwell, John
Subject: Re: [Sip] Terminology (was RE:
Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

 

 
Mary. 

/Hans Erik van Elburg

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 12 Mar 2009 17:17:02 +0100

Yes. RFC3455, section 4.2.2.2.

/Hans Erik van Elburg

On Thu, Mar 12, 2009 at 4:11 PM, Francois Audet <[email-masked]> wrote:

> On Mar 12, 2009, at 7:07, "Christer Holmberg" <
> [email-masked]> wrote:
>
>
>  Hi,
>
> IF we would remove that requierment, and ONLY care about the case when the
> R-URI is replaced with the CONTACT, I don't think we need to do anything. I
> believe P-Called-Party-ID already solves that.
>
> Regards,
>
> Christer
>
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Elwell, John
> *Sent:* 12. maaliskuuta 2009 15:31
> *To:* Hans Erik van Elburg
> *Cc:* <[email-masked]>[email-masked]
> *Subject:* Re: [Sip] Terminology (was RE: Fwd:
> The way I interpreted the 01 draft, you would not get the freephone number
> anyway. If that is a requirement, then I accept my suggestion won't suffice
> .
>
> John
>
>  ------------------------------
> *From:* Hans Erik van Elburg [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* 12 March 2009 12:57
> *To:* Elwell, John
> *Cc:* <[email-masked]>[email-masked]
> *Subject:* Re: [Sip] Terminology (was RE: Fwd:
> represents a use case where the R-URI is replaced with an AoR of user B -
> not with the contact of user B.
>
> The target-uri draft is interested in obtaining: Bfreephonenumber as that
> is what A used to reach B.
>
> On Thu, Mar 12, 2009 at 12:08 PM, Elwell, John < <[email-masked]>
> [email-masked]> wrote:
>
>>        From: <[email-masked]>[email-masked] [mailto:<[email-masked]>
>> [email-masked]] On
>>        Cc: <[email-masked]>[email-masked]
>> < <[email-masked]>[email-masked]> wrote:
>>
>>
>>                Responses below [MB].
>>
>>
>> [mailto: <[email-masked]>[email-masked]]
>>
>>                Cc: Shida Schubert; <[email-masked]>[email-masked]
> Sip mailing list   <https://www.ietf.org/mailman/listinfo/sip>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 12 Mar 2009 17:41:22 +0100

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 

> Behalf Of Mary Barnes
> Sent: Wednesday, March 11, 2009 4:27 PM
> To: Dean Willis; Shida Schubert
> Cc: [email-masked]
> 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. 
>

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Mar 2009 13:10:16 -0500

I think there is another solution proposal that we should pursue for
issue 3 identified in the email summary sent by Shida earlier this week
- I've snipped all the text except for that issue and issue 2 in the
summary below.  I do think the discussion has confounded the two issues
and I think it ought to be clarified that if we agree to the two tags
per issue 3, that the options for the terminology MUST change. And,
perhaps this is why the other discussion threads aren't progressing
well.
 
So, Hans Erick, I would like clarification on as to your view on the
solution:
 
In general, ISTM that one of the issues we're having in this terminology
thread is that you are considering the solution to be that the
hi-entries are tagged as they 
are added to the request.  And, just for clarification from my
perspective, that is NOT the solution in either 4244bis or target-uri. 
 
I don't view it as a problem necessarily if you'd like to pursue an
alternate solution, we just need to be clear that's what you're
advocating. In that case, I would agree the "retarget" is not an
appropriate tag for the entries, as you don't know at the point in time
that you add an hi-entry that it will be retargeted. In the case of this
approach to the solution, you do have to alter the mechanism for
determining the hi-entry that your services would want to use. You would
need to skip the most recent/last hi-entry (as that would contain the
same as the Request-URI in the incoming request), since it would be
tagged if you use this solution approach. Thus, you'd have to take the
next hi-entry that you find that has the desired "tag".  I will posit
that we could accomplish this solution without any changes to 4244 by
just registering new SIP URI parameter(s).   And,  that's not to say we
shouldn't do a 4244bis as there are other issues to address in that
document, but that allows the target-uri to describe a solution that
makes use of 4244bis "as is".
 
So, feedback on this specific point (from Hans Erik and others) would be
appreciated. 
 
Mary.

From: Shida Schubert [mailto:[email-masked]] 
Sent: Wednesday, March 11, 2009 1:13 AM
To: [email-masked] List
Cc: Barnes, Mary (RICH2:AR00)
Subject: Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt 

 
 
Note, that the target-uri document still contains the normative text for
the
History-Info header.

 

::Issues::

      "target-identity" (someone didn't like that "identity" is also a
SIP header)
 
      in the context of the former situation and "retarget" for the case

     
     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).

Regards,
Shida and Mary.

Begin forwarded message:

	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.

	
	
	Below is the data which will enable a MIME compliant mail reader
	implementation to automatically retrieve the ASCII version of
the
	Internet-Draft.

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Mar 2009 13:15:42 -0500

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:[email-masked]] 
Sent: Thursday, March 12, 2009 11:41 AM
To: Barnes, Mary (RICH2:AR00); Dean Willis; Shida Schubert
Cc: [email-masked]
Subject: RE: [Sip] Fwd:

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 

> Mary Barnes
> forwarding" or "request forwarding" for this particular case. As long 
> as we can be precise in 4244bis, then that should suffice for now, but

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Mar 2009 13:19:49 -0500

Sorry Keith ... I forgot to snip and transform to text. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Barnes, Mary (RICH2:AR00)
Sent: Thursday, March 12, 2009 1:10 PM
To: Hans Erik van Elburg; [email-masked]
Subject: [Sip] Issue 3 - two tags (was RE:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

 

 
Mary.

....snipped...

     

 
Regards,
Shida and Mary.

Begin forwarded message:

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 12 Mar 2009 19:18:16 +0100

Hi Mary,
 
A couple of question:
 
1. Does the 4244bis definition of "retarget" cover the freephone case,
when the R-URI is replaced with the AoR of B - not with the contact of B
- no matter whether it's done based on location service, configuration
or whatever?
 
2. Related to the first question, when you say "...and thus chaning the
target of the request", what is the defintion of "target"?
 
Regards,
 
Christer

Sent: Thursday, March 12, 2009 5:20 PM

 

 
Mary. 

/Hans Erik van Elburg

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Mar 2009 13:36:49 -0500

Responses below [MB].

From: Christer Holmberg [mailto:[email-masked]] 
Sent: Thursday, March 12, 2009 1:18 PM
To: Barnes, Mary (RICH2:AR00); Hans Erik van Elburg
Cc: [email-masked]; Elwell, John
Subject: RE: [Sip] Terminology (was RE:
Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

Hi Mary,
 
A couple of question:
 
1. Does the 4244bis definition of "retarget" cover the freephone case,
when the R-URI is replaced with the AoR of B - not with the contact of B
- no matter whether it's done based on location service, configuration
or whatever?
[MB] That was the intention, however, the current text needs to be made
more general (i.e., I was using location service to mean more than
registration based contacts - another thing that's not quite so clear in
3261). [/MB]
 
2. Related to the first question, when you say "...and thus chaning the
target of the request", what is the defintion of "target"?
[MB] The definition of target matches that used in section 16.5 of 3261.
A target is an entry in the target list, which is populated using
information from a location service, configuration, etc. I can clarify
that as well and as you previously suggested make a more comprehensive
glossary in the more conventional format - e.g., "Target: definition
text, blah, blah, blah...] So, I believe it is the same use of target as
in the target-uri draft. [/MB]
 
Regards,
 
Christer

 

 
 
Mary. 

/Hans Erik van Elburg

---

From: Dean Willis <[email-masked]>
Date: Thu, 12 Mar 2009 14:27:53 -0500

On Mar 12, 2009, at 1:18 PM, Christer Holmberg wrote:

> A couple of question:
>
> 1. Does the 4244bis definition of "retarget" cover the freephone  
> case, when the R-URI is replaced with the AoR of B - not with the  
> contact of B - no matter whether it's done based on location  
> service, configuration or whatever?

By the way, I believe that the way I use the words, this is a  
"reroute" and not a "retarget". In the freephone case, I would still  
expect the destination to have an awareness that it is the target of  
freephone calls and have credentials for the freephone number such  
that it could appropriately authenticate its responses if we had a  
means to do so.

>
> 2. Related to the first question, when you say "...and thus chaning  
> the target of the request", what is the defintion of "target"?
>

My definition is that a "retarget" changes the expected identity of  
the expected responder, introducing the possibility of an  
"unanticipated respondent" scenario.

This is, AFAIK, very different from the 4244 terminology, which I've  
always held to be not particularly useful.

--
Dean

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 12 Mar 2009 22:25:56 +0100

Inline...

/Hans Erik van Elburg

On Thu, Mar 12, 2009 at 7:10 PM, Mary Barnes <[email-masked]> wrote:

> issue 3 identified in the email summary sent by Shida earlier this week -
> I've snipped all the text except for that issue and issue 2 in the summary
> below.  I do think the discussion has confounded the two issues and I think
> it ought to be clarified that if we agree to the two tags per issue 3, that
> the options for the terminology MUST change. And, perhaps this is why the
> other discussion threads aren't progressing well.
>

Agree.

> thread is that you are considering the solution to be that the hi-entries
> are tagged as they
> are added to the request.  And, just for clarification from my perspective,
> that is NOT the solution in either 4244bis or target-uri.
>
>
The principle should be that the node that has the information about what
type of rewrite is performed should add the tag. (This is done by the
current target-uri draft allthough the solution is not complete.)

For the freephone service, that would be the freephone service. For the AOR
that is the home proxy.

Assume that the freephone service receives an INVITE  request that either
1. received request contains History-Info header that contains the freephone
number (as in R-URI) as last entry, THEN when rewriting the Request-URI it
has to tag that existing received entry AND add the new entry with the new
value of the Request-URI. (I think that was how History-Info works right.)
2. received request contains History-Info header that does not contain the
freephone number as last entry, THEN when rewriting the Request-URI it has
add an entry with the freephone number and tag that entry AND add the new
entry with the new value of the Request-URI.
3. received request does not contain a History-Info header, THEN when
rewriting the Request-URI it has to add an entry with the freephone number
and tag that entry AND add the new entry with the new value of the
Request-URI.

After forwarding this request it arrives at the home proxy:
1. received request contains History-Info header that contains the AOR (as
in R-URI) as last entry, THEN when rewriting the Request-URI it has to tag
that existing received entry AND add the new entry with the new value of the
Request-URI i.e. the registered contact. (I think that was how History-Info
works right.)
2. received request contains History-Info header that does not contain the
AOR (as in R-URI) as last entry, THEN when rewriting the Request-URI it has
add an entry with the AOR and tag that entry AND add the new entry with the
new value of the Request-URI i.e. the registered contact.
3. received request does not contain a History-Info header, THEN when
rewriting the Request-URI it has to add an entry with the AOR as in the
Request-URI and tag that entry AND add the new entry with the new value of
the Request-URI i.e. the registered contact..

> alternate solution, we just need to be clear that's what you're advocating.
> In that case, I would agree the "retarget" is not an appropriate tag for the
> entries, as you don't know at the point in time that you add an hi-entry
> that it will be retargeted. In the case of this approach to the solution,
> you do have to alter the mechanism for determining the hi-entry that your
> services would want to use. You would need to skip the most recent/last
> hi-entry (as that would contain the same as the Request-URI in the incoming
> request), since it would be tagged if you use this solution approach.
>

Yes, but only if the previous proxy added it. As History-Info is optional
one never knows really.

> Thus, you'd have to take the next hi-entry that you find that has the
> desired "tag".  I will posit that we could accomplish this solution without
> any changes to 4244 by just registering new SIP URI parameter(s).   And,
>  that's not to say we shouldn't do a 4244bis as there are other issues to
> address in that document, but that allows the target-uri to describe a
> solution that makes use of 4244bis "as is".
>
>
Are you proposing to decouple the target-uri and the 4244bis discussion?

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 12 Mar 2009 22:51:22 +0100

Hi Mary, 

>registration based contacts - another thing that's not quite so clear
in

[CH] We can fix the text. I just wanted to make sure that you agree on
the principle.

>in the target-uri draft. [/MB]

[CH] Ok.

Regards,
 
Christer

 

 
 
Mary. 

/Hans Erik van Elburg

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 13 Mar 2009 11:18:42 +0100

Hi Dean,

Yes this was exactly how we used/defined the terms at the time we where
discussing the ua-loose-route vs Target-header solutions.

I still think that this way they are most intuitive and closest to how you
would use the terms in natural language.

/Hans Erik van Elburg

On Thu, Mar 12, 2009 at 8:27 PM, Dean Willis <[email-masked]>wrote:

>> when the R-URI is replaced with the AoR of B - not with the contact of B -
>> no matter whether it's done based on location service, configuration or
>> whatever?
>>
>
> By the way, I believe that the way I use the words, this is a "reroute" and
> not a "retarget". In the freephone case, I would still expect the
> destination to have an awareness that it is the target of freephone calls
> and have credentials for the freephone number such that it could
> appropriately authenticate its responses if we had a means to do so.
>
>
> My definition is that a "retarget" changes the expected identity of the
> expected responder, introducing the possibility of an "unanticipated
> respondent" scenario.
>
> This is, AFAIK, very different from the 4244 terminology, which I've always
> held to be not particularly useful.
>
> --
> Dean
>
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 13 Mar 2009 12:41:42 +0100

Hi,
 
I think we should use those definitions as base. That way I think we
would be able to progress faster.
 
Because, I think we really need to agree on the definitions FIRST. There
is no idea on discussing detailed wording in 4244bis if we don't have a
common understanding of what we mean.
 
Regards,
 
Christer

	From: Hans Erik van Elburg [mailto:[email-masked]] 
	Sent: 13. maaliskuuta 2009 12:19
	To: Dean Willis
	Cc: Christer Holmberg; Mary Barnes; [email-masked]; Elwell, John
	Subject: Re: [Sip] Terminology (was RE:
Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

	Hi Dean,
	
	Yes this was exactly how we used/defined the terms at the time
we where discussing the ua-loose-route vs Target-header solutions.
	
	I still think that this way they are most intuitive and closest
to how you would use the terms in natural language. 
	
	/Hans Erik van Elburg

	On Thu, Mar 12, 2009 at 8:27 PM, Dean Willis
<[email-masked]> wrote:

			A couple of question:
			
			1. Does the 4244bis definition of "retarget"
cover the freephone case, when the R-URI is replaced with the AoR of B -
not with the contact of B - no matter whether it's done based on
location service, configuration or whatever?

		By the way, I believe that the way I use the words, this
is a "reroute" and not a "retarget". In the freephone case, I would
still expect the destination to have an awareness that it is the target
of freephone calls and have credentials for the freephone number such
that it could appropriately authenticate its responses if we had a means
to do so. 

			2. Related to the first question, when you say
"...and thus chaning the target of the request", what is the defintion
of "target"?

		My definition is that a "retarget" changes the expected
identity of the expected responder, introducing the possibility of an
"unanticipated respondent" scenario.
		
		This is, AFAIK, very different from the 4244
terminology, which I've always held to be not particularly useful.
		
		--
		Dean

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 13 Mar 2009 14:24:30 +0000

Hans Erik,

Following your detailed description, it seems that the UAS serving a
freephone number could receive one of the following (assuming H-I is
supported by all relevant nodes):

1) H-I containing:
- the freephone number (tagged);
- the AoR (tagged);
- the contact URI (not tagged).

Or

2) H-I containing: 
- the freephone number (tagged);
- the contact URI (not tagged).

The latter would occur when the same proxy translates the freephone
number (via the AoR) to the contact directly.

So how does this help the UAS to figure out the freephone number? It
seems the UAS would have to search back through the tagged entries
looking for one that matches a freephone number it recognises? Does the
tagging really add much value?

John

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hans Erik van Elburg
	Sent: 12 March 2009 21:26
	To: Mary Barnes
	Cc: Hans Erik van Elburg; [email-masked]
	Subject: Re: [Sip] Issue 3 - two tags (was RE:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

	Inline...
	
	/Hans Erik van Elburg

	On Thu, Mar 12, 2009 at 7:10 PM, Mary Barnes
<[email-masked]> wrote:

		I think there is another solution proposal that we
should pursue for issue 3 identified in the email summary sent by Shida
earlier this week - I've snipped all the text except for that issue and
issue 2 in the summary below.  I do think the discussion has confounded
the two issues and I think it ought to be clarified that if we agree to
the two tags per issue 3, that the options for the terminology MUST
change. And, perhaps this is why the other discussion threads aren't
progressing well.

	Agree.

		So, Hans Erick, I would like clarification on as to your
view on the solution:
		 
		In general, ISTM that one of the issues we're having in
this terminology thread is that you are considering the solution to be
that the hi-entries are tagged as they 
		are added to the request.  And, just for clarification
from my perspective, that is NOT the solution in either 4244bis or
target-uri. 

	The principle should be that the node that has the information
about what type of rewrite is performed should add the tag. (This is
done by the current target-uri draft allthough the solution is not
complete.)
	
	For the freephone service, that would be the freephone service.
For the AOR that is the home proxy.
	
	Assume that the freephone service receives an INVITE  request
that either  
	1. received request contains History-Info header that contains
the freephone number (as in R-URI) as last entry, THEN when rewriting
the Request-URI it has to tag that existing received entry AND add the
new entry with the new value of the Request-URI. (I think that was how
History-Info works right.)
	2. received request contains History-Info header that does not
contain the freephone number as last entry, THEN when rewriting the
Request-URI it has add an entry with the freephone number and tag that
entry AND add the new entry with the new value of the Request-URI.
	3. received request does not contain a History-Info header, THEN
when rewriting the Request-URI it has to add an entry with the freephone
number and tag that entry AND add the new entry with the new value of
the Request-URI.
	
	After forwarding this request it arrives at the home proxy:
	1. received request contains History-Info header that contains
the AOR (as in R-URI) as last entry, THEN when rewriting the Request-URI
it has to tag that existing received entry AND add the new entry with
the new value of the Request-URI i.e. the registered contact. (I think
that was how History-Info works right.)
	2. received request contains History-Info header that does not
contain the AOR (as in R-URI) as last entry, THEN when rewriting the
Request-URI it has add an entry with the AOR and tag that entry AND add
the new entry with the new value of the Request-URI i.e. the registered
contact.
	3. received request does not contain a History-Info header, THEN
when rewriting the Request-URI it has to add an entry with the AOR as in
the Request-URI and tag that entry AND add the new entry with the new
value of the Request-URI i.e. the registered contact..

		I don't view it as a problem necessarily if you'd like
to pursue an alternate solution, we just need to be clear that's what
you're advocating. In that case, I would agree the "retarget" is not an
appropriate tag for the entries, as you don't know at the point in time
that you add an hi-entry that it will be retargeted. In the case of this
approach to the solution, you do have to alter the mechanism for
determining the hi-entry that your services would want to use. You would
need to skip the most recent/last hi-entry (as that would contain the
same as the Request-URI in the incoming request), since it would be
tagged if you use this solution approach.

	Yes, but only if the previous proxy added it. As History-Info is
optional one never knows really.

		Thus, you'd have to take the next hi-entry that you find
that has the desired "tag".  I will posit that we could accomplish this
solution without any changes to 4244 by just registering new SIP URI
parameter(s).   And,  that's not to say we shouldn't do a 4244bis as
there are other issues to address in that document, but that allows the
target-uri to describe a solution that makes use of 4244bis "as is".

	Are you proposing to decouple the target-uri and the 4244bis
discussion?

		So, feedback on this specific point (from Hans Erik and
others) would be appreciated. 

		Mary.

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 13 Mar 2009 09:30:35 -0500

That's fine - we just need to be careful with the wording in 4244 so
that the existing normative functionality isn't so impacted. I'll look
at the detailed impact of the changes as retarget is quite prevalent in
that document. It could be that we can leave it in the early sections
(and define it to be the same as the term we agree) and just keep it out
of the normative sections - right now, it is only used in a few places
other than describing the new parameter in the normative sections.
 
Mary.

From: Christer Holmberg [mailto:[email-masked]] 
Sent: Friday, March 13, 2009 6:42 AM
To: Hans Erik van Elburg; Dean Willis
Cc: Barnes, Mary (RICH2:AR00); [email-masked]; Elwell, John
Subject: RE: [Sip] Terminology (was RE:
Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

Hi,

 
Regards,
 
Christer

	Hi Dean,

	
	/Hans Erik van Elburg

			A couple of question:

		
		
		--
		Dean

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 13 Mar 2009 15:33:16 +0100

Hi John,

Well that is simple one would use different tags for different type of
entries, like in the example I already gave:

Where the UAS interested in the initial target with which it was addressed
it would obtain the "istarget" tagged entry.
Where the UAS interested in the AOR  that was used to address it would
obtain the "aor" tagged entry.

In simpler cases it could be that one entry holds the "aor" as well as the
"istarget" tag.

Of course the algorithm needs some work to make it complete.

/Hans Erik van Elburg

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 13 Mar 2009 09:39:28 -0500

So, it appears we are both talking about the solutions that are
currently described in 4244bis and target-uri (they are the same and one
in 4244bis is more complete than the one in target-uri for obvious
reasons). I view this solution to be tagging the entries with the
"action" (whatever we call it) that resulted in the uri reflected in the
hi-entry in the incoming request being overwritten by a "new"
Request-URI in the outgoing request.  Whereas, I had been concerned that
the solution you had in mind was one whereby we were tagging the "new"
Request-URI with the action that resulted in the "new" request URI.  So
your response clears my confusion, so we'll ignore the alternative
suggestion (as that would only apply to that latter view of the solution
- i.e., the one suggested below).
 
Thanks,
Mary. 

From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Thursday, March 12, 2009 4:26 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Hans Erik van Elburg; [email-masked]
Subject: Re: [Sip] Issue 3 - two tags (was RE: I-D
ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

Inline...

/Hans Erik van Elburg

On Thu, Mar 12, 2009 at 7:10 PM, Mary Barnes <[email-masked]>
wrote:

>	I think there is another solution proposal that we should pursue
for issue 3 identified in the email 
> summary sent by Shida earlier this week - I've snipped all the text
except for that issue and issue 2 in the 
> summary below.  I do think the discussion has confounded the two
issues and I think it ought to be clarified 
> that if we agree to the two tags per issue 3, that the options for the
terminology MUST change. And, perhaps 
> this is why the other discussion threads aren't progressing well.

Agree.

> 	So, Hans Erick, I would like clarification on as to your view on
the solution:
	 
> 	In general, ISTM that one of the issues we're having in this
terminology thread is that you are considering the 
> solution to be that the hi-entries are tagged as they 
perspective, that is NOT the solution in either
>  4244bis or target-uri. 

The principle should be that the node that has the information about
what type of rewrite is performed should add the tag. (This is done by
the current target-uri draft allthough the solution is not complete.)

For the freephone service, that would be the freephone service. For the
AOR that is the home proxy.

Assume that the freephone service receives an INVITE  request that
either  
1. received request contains History-Info header that contains the
freephone number (as in R-URI) as last entry, THEN when rewriting the
Request-URI it has to tag that existing received entry AND add the new
entry with the new value of the Request-URI. (I think that was how
History-Info works right.)
2. received request contains History-Info header that does not contain
the freephone number as last entry, THEN when rewriting the Request-URI
it has add an entry with the freephone number and tag that entry AND add
the new entry with the new value of the Request-URI.
3. received request does not contain a History-Info header, THEN when
rewriting the Request-URI it has to add an entry with the freephone
number and tag that entry AND add the new entry with the new value of
the Request-URI.

After forwarding this request it arrives at the home proxy:
1. received request contains History-Info header that contains the AOR
(as in R-URI) as last entry, THEN when rewriting the Request-URI it has
to tag that existing received entry AND add the new entry with the new
value of the Request-URI i.e. the registered contact. (I think that was
how History-Info works right.)
2. received request contains History-Info header that does not contain
the AOR (as in R-URI) as last entry, THEN when rewriting the Request-URI
it has add an entry with the AOR and tag that entry AND add the new
entry with the new value of the Request-URI i.e. the registered contact.
3. received request does not contain a History-Info header, THEN when
rewriting the Request-URI it has to add an entry with the AOR as in the
Request-URI and tag that entry AND add the new entry with the new value
of the Request-URI i.e. the registered contact..

>	I don't view it as a problem necessarily if you'd like to pursue
an alternate solution, we just need to be clear 
> that's what you're advocating. In that case, I would agree the
"retarget" is not an appropriate tag for the entries,
> as you don't know at the point in time that you add an hi-entry that
it will be retargeted. In the case of this 
> approach to the solution, you do have to alter the mechanism for
determining the hi-entry that your services would 
> want to use. You would need to skip the most recent/last hi-entry (as
that would contain the same as the Request-URI
 > in the incoming request), since it would be tagged if you use this
solution approach.

>	Thus, you'd have to take the next hi-entry that you find that
has the desired "tag".  I will posit that we could 
> accomplish this solution without any changes to 4244 by just
registering new SIP URI parameter(s).   And,  that's not
> to say we shouldn't do a 4244bis as there are other issues to address
in that document, but that allows the target-uri
>  to describe a solution that makes use of 4244bis "as is".

>	So, feedback on this specific point (from Hans Erik and others)
would be appreciated. 

	Mary.

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 13 Mar 2009 14:39:48 +0000

Hans Erik,

But how does a proxy know what to use? How does it know whether the
received Request-URI, which it uses to query the LS, is a target or an
AoR? Does it need to scan back up the H-I chain to see whether there is
already an 'istarget' present, and if so use 'aor' instead of
'istarget'?

John

	From: Hans Erik van Elburg [mailto:[email-masked]] 
	Sent: 13 March 2009 14:33
	To: Elwell, John
	Cc: [email-masked]
	Subject: Re: [Sip] Issue 3 - two tags (was RE:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

	Hi John,
	
	Well that is simple one would use different tags for different
type of entries, like in the example I already gave:

	Where the UAS interested in the initial target with which it was
addressed it would obtain the "istarget" tagged entry.
	Where the UAS interested in the AOR  that was used to address it
would obtain the "aor" tagged entry.
	 
	In simpler cases it could be that one entry holds the "aor" as
well as the "istarget" tag.

	/Hans Erik van Elburg

	On Fri, Mar 13, 2009 at 3:24 PM, Elwell, John
<[email-masked]> wrote:

		Hans Erik,
		
		Following your detailed description, it seems that the
UAS serving a
		freephone number could receive one of the following
(assuming H-I is
		supported by all relevant nodes):
		
		1) H-I containing:
		
		Or
		
		2) H-I containing:
		
		The latter would occur when the same proxy translates
the freephone
		number (via the AoR) to the contact directly.
		
		So how does this help the UAS to figure out the
freephone number? It
		seems the UAS would have to search back through the
tagged entries
		looking for one that matches a freephone number it
recognises? Does the
		tagging really add much value?
		
		John

		       Inline...
		
		       /Hans Erik van Elburg

		               I think there is another solution
proposal that we
		should pursue for issue 3 identified in the email
summary sent by Shida
		earlier this week - I've snipped all the text except for
that issue and
		issue 2 in the summary below.  I do think the discussion
has confounded
		the two issues and I think it ought to be clarified that
if we agree to
		the two tags per issue 3, that the options for the
terminology MUST
		change. And, perhaps this is why the other discussion
threads aren't
		progressing well.

		       Agree.

		               So, Hans Erick, I would like
clarification on as to your
		view on the solution:
		
		               In general, ISTM that one of the issues
we're having in
		this terminology thread is that you are considering the
solution to be
		that the hi-entries are tagged as they
		               are added to the request.  And, just for
clarification
		from my perspective, that is NOT the solution in either
4244bis or
		target-uri.

		       The principle should be that the node that has
the information
		about what type of rewrite is performed should add the
tag. (This is
		done by the current target-uri draft allthough the
solution is not
		complete.)
		
		       For the freephone service, that would be the
freephone service.
		For the AOR that is the home proxy.
		
		       Assume that the freephone service receives an
INVITE  request
		that either
		       1. received request contains History-Info header
that contains
		the freephone number (as in R-URI) as last entry, THEN
when rewriting
		the Request-URI it has to tag that existing received
entry AND add the
		new entry with the new value of the Request-URI. (I
think that was how
		History-Info works right.)
		       2. received request contains History-Info header
that does not
		contain the freephone number as last entry, THEN when
rewriting the
		Request-URI it has add an entry with the freephone
number and tag that
		entry AND add the new entry with the new value of the
Request-URI.
		       3. received request does not contain a
History-Info header, THEN
		when rewriting the Request-URI it has to add an entry
with the freephone
		number and tag that entry AND add the new entry with the
new value of
		the Request-URI.
		
		       After forwarding this request it arrives at the
home proxy:
		       1. received request contains History-Info header
that contains
		the AOR (as in R-URI) as last entry, THEN when rewriting
the Request-URI
		it has to tag that existing received entry AND add the
new entry with
		the new value of the Request-URI i.e. the registered
contact. (I think
		that was how History-Info works right.)
		       2. received request contains History-Info header
that does not
		contain the AOR (as in R-URI) as last entry, THEN when
rewriting the
		Request-URI it has add an entry with the AOR and tag
that entry AND add
		the new entry with the new value of the Request-URI i.e.
the registered
		contact.
		       3. received request does not contain a
History-Info header, THEN
		when rewriting the Request-URI it has to add an entry
with the AOR as in
		the Request-URI and tag that entry AND add the new entry
with the new
		value of the Request-URI i.e. the registered contact..

		               I don't view it as a problem necessarily
if you'd like
		to pursue an alternate solution, we just need to be
clear that's what
		you're advocating. In that case, I would agree the
"retarget" is not an
		appropriate tag for the entries, as you don't know at
the point in time
		that you add an hi-entry that it will be retargeted. In
the case of this
		approach to the solution, you do have to alter the
mechanism for
		determining the hi-entry that your services would want
to use. You would
		need to skip the most recent/last hi-entry (as that
would contain the
		same as the Request-URI in the incoming request), since
it would be
		tagged if you use this solution approach.

		       Yes, but only if the previous proxy added it. As
History-Info is
		optional one never knows really.

		               Thus, you'd have to take the next
hi-entry that you find
		that has the desired "tag".  I will posit that we could
accomplish this
		solution without any changes to 4244 by just registering
new SIP URI
		parameter(s).   And,  that's not to say we shouldn't do
a 4244bis as
		there are other issues to address in that document, but
that allows the
		target-uri to describe a solution that makes use of
4244bis "as is".

		       Are you proposing to decouple the target-uri and
the 4244bis
		discussion?

		               So, feedback on this specific point (from
Hans Erik and
		others) would be appreciated.

		               Mary.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 13 Mar 2009 15:51:59 +0100

It knows when it rewrites the Request-URI due to a location lookup --> tag
"aor".
It knows (is configured to) when it rewrites the Request-URI with a value
that leads the request to target with a different identity then the one that
has been replaced --> tag new entry "istarget".
It knows when it rewrites the Request-URI with a value and this leads to the
first History-Info entry being recorded --> tag "istarget".

/Hans Erik van Elburg

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 13 Mar 2009 16:31:14 +0000

> Sent: 13 March 2009 14:52
> To: Elwell, John
> Cc: [email-masked]
> It knows when it rewrites the Request-URI due to a location 
> lookup --> tag "aor".
> It knows (is configured to) when it rewrites the Request-URI 
> with a value that leads the request to target with a 
> different identity then the one that has been replaced --> 
> tag new entry "istarget".
> It knows when it rewrites the Request-URI with a value and 
> this leads to the first History-Info entry being recorded --> 
> tag "istarget".
[JRE] It does not know that this is the first target, because upstream
nodes may have retargeted without inserting H-I. In any case, the To
header field URI is the first target, so we don't need that anyway.

I can accept that a proxy might know, having done a LS look-up, whether
the new URI is a registered contact or some other URI, and on that basis
it could choose whether or not to insert a single tag. I thought that
was the basis on which we agreed to go ahead with this updated to RFC
4424, rather than following the loose route draft. It is not clear to me
that a proxy would have enough information to make a 3-way choice.

John

> 
> /Hans Erik van Elburg
> 
> 
> 
> On Fri, Mar 13, 2009 at 3:39 PM, Elwell, John

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 13 Mar 2009 17:59:12 +0100

3-way choice?

A proxy that has retargeting logic knows when it is doing so.
A proxy that has rerouting logic to registered contact knows when it is
doing so.

No 3-way magic there.

And yes the History-Info is optional so you never know if all nodes in the
chain do there bit. But that is fact of life. As long as you can ensure that
in your domain it is supported you will receive  correct information.

/Hans Erik van Elburg

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 13 Mar 2009 13:43:44 -0500

Hi John,

Thanks for all your feedback thus far on this topic. I have a couple
comments below [MB].

Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Elwell, John
Sent: Friday, March 13, 2009 11:31 AM
To: Hans Erik van Elburg
Cc: [email-masked]
Subject: Re: [Sip] Issue 3 - two tags (was RE:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

> It knows when it rewrites the Request-URI due to a location lookup -->

> tag "aor".
> It knows (is configured to) when it rewrites the Request-URI with a 
> value that leads the request to target with a different identity then 
> the one that has been replaced --> tag new entry "istarget".
> It knows when it rewrites the Request-URI with a value and this leads 
> to the first History-Info entry being recorded --> tag "istarget".
[JRE] It does not know that this is the first target, because upstream
nodes may have retargeted without inserting H-I. In any case, the To
header field URI is the first target, so we don't need that anyway.
[MB] John is correct. There is no rule about tagging the first
History-Info entry. It may be tagged if the next node changes the
request-URI via a service lookup or some other manner such as
configuration.[/MB]

I can accept that a proxy might know, having done a LS look-up, whether
the new URI is a registered contact or some other URI, and on that basis
it could choose whether or not to insert a single tag. I thought that
was the basis on which we agreed to go ahead with this updated to RFC
4424, rather than following the loose route draft. It is not clear to me
that a proxy would have enough information to make a 3-way choice.
[MB] My understanding is that there are just two ways in which the
request-URI changes if you are using loose routing. It's either changed
due to a lookup in a location server, whose information was populated by
the UA during registration, OR it is changed due to configuration data
(either system, user, etc.). In both cases, obviously, the proxy that is
doing this is responsible for the domain of the request-URI in the
incoming request. If it were not the case, then all the proxy can do is
forward the outgoing request to the next hop. So, I think that may be
where the concept of a 3rd choice comes in. But, as far as tagging, we
(as I understand it) at least were discussing the potential of two tags
only - i.e., further differentiating the cases that are currently all
captured by the "retarget" as defined in 4244bis, which is the same
mechanism that is specified in the target-uri document EXCEPT that
document was only capturing the service lookups, which we believe is
incorrect. [/MB]

John

> 	received Request-URI, which it uses to query the LS, is a target
or 
> an
> 	AoR? Does it need to scan back up the H-I chain to see whether
there 
> 	       Where the UAS interested in the initial target with which
it 
> 	       Where the UAS interested in the AOR  that was used to
address 
> it
> 	               earlier this week - I've snipped all the text
except 
> for
> 	               the two issues and I think it ought to be
clarified 
> 	               this terminology thread is that you are
considering 
> 	               number and tag that entry AND add the new entry
with 
> 	               the new entry with the new value of the
Request-URI 
> i.e.
> 	               the Request-URI and tag that entry AND add the
new 
> entry
> 	               that you add an hi-entry that it will be
retargeted. 
> 	               determining the hi-entry that your services would
want
> 	               same as the Request-URI in the incoming request),

> since
> 	                      Yes, but only if the previous proxy added
it. 
> As
> 	               that has the desired "tag".  I will posit that we

> could
> 	               there are other issues to address in that
document, 
> but
> 	                      Are you proposing to decouple the
target-uri 
> and
> 	the 4244bis
> 	               discussion?
> 	
> 	
> 	                              So, feedback on this specific
point 
> (from

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 13 Mar 2009 22:17:18 +0100

I guess you mean that you agree with John that such rule can not be reliably
construed.
I dont think I have seen convincing proof that such is the case.

Are you also saying that we may only consider loose routing being used?

Further for "configured mappings" for which we never saw a proper
definition. But assuming that this is a proxy that can be configured to do a
Request-URI  rewrite based on some configured setting.

In that case there are two variants of such mapping:
1. A mapping that changes the identity of the target to be reached. (This is
what call forwarding or diversion does normally.)
2. A mapping that only changes  the next hop route taken towards the target
identity that has not been changed.

For the UAS it only matters that the home domain does the tagging
consistently and correctly if it wants to rely on such information.

Otherwise we would have to start adding information about the domain that
added a specific hi-entry, if one wants to be sure who added the particular
hi-entry.

/Hans Erik van Elburg

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 13 Mar 2009 16:53:35 -0500

Responses below [MB].

Sent: Friday, March 13, 2009 4:17 PM

I guess you mean that you agree with John that such rule can not be
reliably construed. 
[MB] Which rule?  I fully agree we can discern the 3 cases as I
explained below. Per 16.5 (Determining Request Targets) in RFC 3261,
these are unique and recognized situations. The reason I refer to loose
routing is that it's my understanding it is far more commonly used and
RFC 3261 doesn't even describe strict routing - it focuses on loose
routing and strict routing support is for 2543 backwards compatibility
as I understood. But, actually it makes no difference to History-Info
processing.  The important thing really, is that you MUST tag the old
entry as you are doing the processing per 16.5 as that information is
lost by the time you get around to adding the next History-Info header
in section 16.6 ( Request Forwarding). I think one thing that might be
being missed in this thread is that I have been very careful to rely
explicitly on what is described in 16.5 - that a must read to understand
what I am saying - again there is a lack of clarity in that section and
we can suggest clarifications once we all can finally agree appropriate
terms. If you'd like me to pull the explicit text that supports
everything I've been saying, I can do so, but it's somewhat a waste of
time. [/MB]
 
I dont think I have seen convincing proof that such is the case. 
[MB] And, I'm not saying that you can't construct such a rule - indeed I
am saying that you certainly should be able to per RFC 3261 section
16.5.  Can you point out what text below that suggests I am saying that?
[/MB] 

[MB] Nope. [/MB] 

Further for "configured mappings" for which we never saw a proper
definition. But assuming that this is a proxy that can be configured to
do a Request-URI  rewrite based on some configured setting. 
[MB] The concept of "configured mappings" is described in RFC 3261 -
perhaps not with the level of granularity or specificity that some might
desire, but it's there - it's initially described as an abstract
location service (1st Paragraph section 16.5).  And, then later it
specifies that a proxy can determine "targets" (3261 term not mine) just
about any ole way it wants, so I don't know that we need to define a new
term for "configured mappings" per se - there is no limitation as to the
mechanism one can use to determine the request-URI for the outgoing
request (once it is determined that the Proxy is ALLOWED  to overwrite
the request-URI - the right domain, etc.),  This is a fundamental SIP
concept that many products use to give a (human) user flexibility in
configuring where an incoming call might terminate. So, I see no issue
at all is specifying two tags to capture this rewrite as it's already in
section 16.5 that this is information that a Proxy should be able to
derive. [/MB] 

In that case there are two variants of such mapping:
1. A mapping that changes the identity of the target to be reached.
(This is what call forwarding or diversion does normally.)
2. A mapping that only changes  the next hop route taken towards the
target identity that has not been changed.   

For the UAS it only matters that the home domain does the tagging
consistently and correctly if it wants to rely on such information. 
[MB] I don't know that I agree it's the home domain - it's a proxy that
has responsibility for the domain in the request-URI that is able to do
the service lookup or using any other sort of mapping to determine the
new URI for the request-URI in the outgoing request.  I don't know that
we want to restrict that to the "home" domain. If we restrict it to the
home domain, then that implies that we are only tagging the entries that
are determined based on service lookup in a Registrar (per RFC 3261's
definition of a "home domain").  [/MB]

Otherwise we would have to start adding information about the domain
that added a specific hi-entry, if one wants to be sure who added the
particular hi-entry. 
[MB] I'm not sure why this would be needed and I wasn't espousing that
it would - we know by definition that the domain that mucked with a URI
is the domain associated with the URI that was overwritten/lost, etc.
[/MB] 

/Hans Erik van Elburg

On Fri, Mar 13, 2009 at 7:43 PM, Mary Barnes <[email-masked]>
wrote:

	Hi John,
	
	Thanks for all your feedback thus far on this topic. I have a
couple
	comments below [MB].
	
	Mary.

	-----Original Message-----
	
	Elwell, John
	
	Cc: [email-masked]

	
	> It knows when it rewrites the Request-URI due to a location
lookup -->
	
	> It knows (is configured to) when it rewrites the Request-URI
with a
	> It knows when it rewrites the Request-URI with a value and
this leads
	> to the first History-Info entry being recorded --> tag
"istarget".
	[JRE] It does not know that this is the first target, because
upstream
	nodes may have retargeted without inserting H-I. In any case,
the To
	header field URI is the first target, so we don't need that
anyway.
	
	[MB] John is correct. There is no rule about tagging the first
	History-Info entry. It may be tagged if the next node changes
the
	request-URI via a service lookup or some other manner such as
	configuration.[/MB]

	I can accept that a proxy might know, having done a LS look-up,
whether
	the new URI is a registered contact or some other URI, and on
that basis
	it could choose whether or not to insert a single tag. I thought
that
	was the basis on which we agreed to go ahead with this updated
to RFC
	4424, rather than following the loose route draft. It is not
clear to me
	that a proxy would have enough information to make a 3-way
choice.
	
	[MB] My understanding is that there are just two ways in which
the
	request-URI changes if you are using loose routing. It's either
changed
	due to a lookup in a location server, whose information was
populated by
	the UA during registration, OR it is changed due to
configuration data
	(either system, user, etc.). In both cases, obviously, the proxy
that is
	doing this is responsible for the domain of the request-URI in
the
	incoming request. If it were not the case, then all the proxy
can do is
	forward the outgoing request to the next hop. So, I think that
may be
	where the concept of a 3rd choice comes in. But, as far as
tagging, we
	(as I understand it) at least were discussing the potential of
two tags
	only - i.e., further differentiating the cases that are
currently all
	captured by the "retarget" as defined in 4244bis, which is the
same
	mechanism that is specified in the target-uri document EXCEPT
that
	document was only capturing the service lookups, which we
believe is
	incorrect. [/MB]

	John

---remainder of theread snipped by Mary. --------

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 13 Mar 2009 23:25:23 +0100

Hi,

I think we shall try to agree on the definitions first - then we can
decide where to put it.

But, wherever we put it, I think there shall be a separate and clear
definitions chapter. Other chapters then simply refers to that.

Regards,

Christer 

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Friday, March 13, 2009 4:31 PM
To: Christer Holmberg; Hans Erik van Elburg; Dean Willis
Cc: [email-masked]; Elwell, John
Subject: RE: [Sip] Terminology (was RE:

Mary.

Hi,

 
Regards,
 
Christer

	Hi Dean,

	
	/Hans Erik van Elburg

			A couple of question:

		
		
		--
		Dean

---

From: Hans Erik van Elburg <[email-masked]>
Date: Sat, 14 Mar 2009 08:54:42 +0100

I just realised that there is an additional problem that makes it even
harder to do any distinction.

A UA may register as a contact an AOR of another user or resource.
Effectively this causes the request to be forwarded to the other user by
overwriting the Request-URI.

So the fact that the Request-URI was overwritten due to a location lookup,
doesn't tell you a bit about the nature of the rewrite.

/Hans Erik van Elburg

---

From: "Mary Barnes" <[email-masked]>
Date: Sat, 14 Mar 2009 09:47:06 -0500

Correct, you don't know anything about the URI that overwrites the
request-URI.   BUT, you know the type of URI that was overwritten (with
respect to how it is used at the incoming Proxy). You know that the
request URI that was overwritten was one of the types we've been
discussing - i.e., a URI that can be used for a service Lookup in a
Registrar, whether that URI is mapped, configured, etc. or whether that
URI is just for a proxy hop - i.e., it's not a URI for which the proxy
is responsible. And, you are using that tag against the URI that is
being overwritten.
 
Mary. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hans Erik van Elburg
Sent: Saturday, March 14, 2009 2:55 AM
To: [email-masked] List
Subject: Re: [Sip] Issue 3 - two tags (was
RE:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

So the fact that the Request-URI was overwritten due to a location
lookup, doesn't tell you a bit about the nature of the rewrite.

/Hans Erik van Elburg

On Fri, Mar 13, 2009 at 10:53 PM, Mary Barnes <[email-masked]>
wrote:

	Responses below [MB].

	

	

	I guess you mean that you agree with John that such rule can not
be
	reliably construed.
	
	[MB] Which rule?  I fully agree we can discern the 3 cases as I
	explained below. Per 16.5 (Determining Request Targets) in RFC
3261,
	these are unique and recognized situations. The reason I refer
to loose
	routing is that it's my understanding it is far more commonly
used and
	RFC 3261 doesn't even describe strict routing - it focuses on
loose
	routing and strict routing support is for 2543 backwards
compatibility
	as I understood. But, actually it makes no difference to
History-Info
	processing.  The important thing really, is that you MUST tag
the old
	entry as you are doing the processing per 16.5 as that
information is
	lost by the time you get around to adding the next History-Info
header
	in section 16.6 ( Request Forwarding). I think one thing that
might be
	being missed in this thread is that I have been very careful to
rely
	explicitly on what is described in 16.5 - that a must read to
understand
	what I am saying - again there is a lack of clarity in that
section and
	we can suggest clarifications once we all can finally agree
appropriate
	terms. If you'd like me to pull the explicit text that supports
	everything I've been saying, I can do so, but it's somewhat a
waste of
	time. [/MB]

	[MB] And, I'm not saying that you can't construct such a rule -
indeed I
	am saying that you certainly should be able to per RFC 3261
section
	16.5.  Can you point out what text below that suggests I am
saying that?
	[/MB]

	Are you also saying that we may only consider loose routing
being used?
	
	[MB] Nope. [/MB]

	Further for "configured mappings" for which we never saw a
proper
	definition. But assuming that this is a proxy that can be
configured to
	do a Request-URI  rewrite based on some configured setting.
	
	[MB] The concept of "configured mappings" is described in RFC
3261 -
	perhaps not with the level of granularity or specificity that
some might
	desire, but it's there - it's initially described as an abstract
	location service (1st Paragraph section 16.5).  And, then later
it
	specifies that a proxy can determine "targets" (3261 term not
mine) just
	about any ole way it wants, so I don't know that we need to
define a new
	term for "configured mappings" per se - there is no limitation
as to the
	mechanism one can use to determine the request-URI for the
outgoing
	request (once it is determined that the Proxy is ALLOWED  to
overwrite
	the request-URI - the right domain, etc.),  This is a
fundamental SIP
	concept that many products use to give a (human) user
flexibility in
	configuring where an incoming call might terminate. So, I see no
issue
	at all is specifying two tags to capture this rewrite as it's
already in
	section 16.5 that this is information that a Proxy should be
able to
	derive. [/MB]

	In that case there are two variants of such mapping:
	1. A mapping that changes the identity of the target to be
reached.
	(This is what call forwarding or diversion does normally.)
	2. A mapping that only changes  the next hop route taken towards
the
	target identity that has not been changed.
	
	For the UAS it only matters that the home domain does the
tagging
	consistently and correctly if it wants to rely on such
information.
	
	[MB] I don't know that I agree it's the home domain - it's a
proxy that
	has responsibility for the domain in the request-URI that is
able to do
	the service lookup or using any other sort of mapping to
determine the
	new URI for the request-URI in the outgoing request.  I don't
know that
	we want to restrict that to the "home" domain. If we restrict it
to the
	home domain, then that implies that we are only tagging the
entries that
	are determined based on service lookup in a Registrar (per RFC
3261's
	definition of a "home domain").  [/MB]

	Otherwise we would have to start adding information about the
domain
	that added a specific hi-entry, if one wants to be sure who
added the
	particular hi-entry.
	
	[MB] I'm not sure why this would be needed and I wasn't
espousing that
	it would - we know by definition that the domain that mucked
with a URI
	is the domain associated with the URI that was overwritten/lost,
etc.
	[/MB]

	/Hans Erik van Elburg

		---remainder of theread snipped by Mary. --------

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 14 Mar 2009 08:10:48 -0700

Yeah, I tought about that too. Not sure how to handle it.

On Mar 14, 2009, at 0:55, "Hans Erik van Elburg" <[email-masked] 

> I just realised that there is an additional problem that makes it  
> even harder to do any distinction.
>
> Effectively this causes the request to be forwarded to the other  
> user by overwriting the Request-URI.
>
> On Fri, Mar 13, 2009 at 10:53 PM, Mary Barnes

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 15 Mar 2009 00:50:16 +0100

When someone is calling the AOR, it will be replaced with the registered
contact. Does it matter is someone else registered the contact/AOR? The
call is not for that someone.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mary Barnes
Sent: Saturday, March 14, 2009 4:47 PM
To: Hans Erik van Elburg; [email-masked]
Subject: Re: [Sip] Issue 3 - two tags
(wasRE:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

Mary. 

/Hans Erik van Elburg

	Responses below [MB].

	

	

	

	
	[MB] Nope. [/MB]

	

	

	/Hans Erik van Elburg

---

From: Hans Erik van Elburg <[email-masked]>
Date: Sun, 15 Mar 2009 20:24:10 +0100

The point is that the registered contact could be an AOR of another user.

/Hans Erik

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 15 Mar 2009 21:30:04 +0100

Hi, 

>The point is that the registered contact could be an AOR of another
user.

Ok, now I understand. Yes, that is an interesting case, eventhough I
guess it's really not the correct usage of the registration procedure.

Regards,

Christer

/Hans Erik

Christer Holmberg wrote:
> When someone is calling the AOR, it will be replaced with the 
> registered contact. Does it matter is someone else registered the 
> contact/AOR? The call is not for that someone.
>
> Regards,
>
> Christer
>
>

---

From: Dean Willis <[email-masked]>
Date: Sun, 15 Mar 2009 20:03:46 -0500

> guess it's really not the correct usage of the registration procedure.

Any contact could be an AOR, not a final destination, in that any UA 
could also decide to become a proxy and send the call somewhere else. 
Such a determination might be made on a call-by-call basis.

In such case, two possibilities apply:

1) the transformation is a reroute, in that the identity of the target 
is not being changed, just the location at which that target is being 
sought.

2) The transformation is a retarget, in that the identity of the target 
is being sought after the transformation is different than the identity 
being sought before the transformation.

Of course, it is possible for a proxy making such a transformation to 
not know the identity of the target. In such a case, it is impossible 
for the proxy to inform the UAC of the transformation and thereby avoid 
an unanticipated respondent scenario. This is the world we live in for 
ALL proxy operations today, and it has its drawbacks.

--
Dean