Subject: Re: [Sip] draft-rosenberg-sip-target-uri-delivery-00.txt: P-Called-Party-ID

From: Shida Schubert <[email-masked]>
Date: Sun, 9 Nov 2008 19:01:38 +0900

I also noticed that on the example call flow in section 4, the
R-URI on the last leg should be that of the contact address
([email-masked]).

  Regards
   Shida

On 31-Oct-08, at 9:51 PM, Christer Holmberg wrote:

>
> Hi,
>
> The draft-holmberg-sip-target-uri-delivery-01.txt draft contained text
> on why the P-Called-Party-ID header was used. Would it be a good  
> idea to
> keep that text in this spec, because I have already received questions
> regarding that.
>
> Regards,
>
> Christer
>
>
>
>
>>> 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
>>> 	Filename        : draft-rosenberg-sip-target-uri-delivery-00.txt
>>> 	Pages           : 12
>>> 	Date            : 2008-10-26
>>>
>>> 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 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- 
>> del
>>> ivery-00.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.
>>> <mime-attachment>_______________________________________________
>>> 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
>>
>> _______________________________________________
>> 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
>>
> _______________________________________________
> 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

_______________________________________________
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: Thu, 13 Nov 2008 10:36:19 -0600

I guess I might be dense, but why can't that be derived from the HI
entry just before the one marked as the "target" entry?  This was the
whole concept behind capturing complete history info - you should always
have the previous request URI and you can build a complete tree of the
retargeting (where RFC 4244 defined that term to include both basic
routing changes to the request URI as well as redirections).

Also, I don't think it's appropriate that it would even be defined in
this doc, even if you need it. You would need a separate doc in SIPPING
and go through the normal expert review process.

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christer Holmberg
Sent: Friday, October 31, 2008 7:52 AM
To: Jonathan Rosenberg
Cc: [email-masked]
Subject: [Sip] draft-rosenberg-sip-target-uri-delivery-00.txt:
P-Called-Party-ID

Hi,

The draft-holmberg-sip-target-uri-delivery-01.txt draft contained text
on why the P-Called-Party-ID header was used. Would it be a good idea to
keep that text in this spec, because I have already received questions
regarding that.

Regards,

Christer

> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-del
> > ivery-00.txt
> >
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 13 Nov 2008 11:34:10 -0600

Actually, I think what you see in the call flow is not the last leg, but the one
before (i.e. to OB-B).

I would suggest that Jonathan adds the last leg to <b>, including the
Request-URI being replaced by the registered contact.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Shida Schubert
> Sent: Sunday, November 09, 2008 02:02
> To: Jonathan Rosenberg
> Cc: [email-masked] List; Christer Holmberg (JO/LMF)
> Subject: Re: [Sip] 
> draft-rosenberg-sip-target-uri-delivery-00.txt: P-Called-Party-ID
> 
> 
>   I also noticed that on the example call flow in section 4, 
> the R-URI on the last leg should be that of the contact 
> address ([email-masked]).
> 
>   Regards
>    Shida
> 
> > on why the P-Called-Party-ID header was used. Would it be a 
> good idea 
> > to keep that text in this spec, because I have already received 
> > questions regarding that.
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 14 Nov 2008 00:15:14 +0100

Hi Mary,

I am not sure I understand what you are saying.

I am not asking to "define" anything. I am just asking to include the text which says why P-CPI can NOT be used.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Mary Barnes [mailto:[email-masked]]
Lähetetty: to 13.11.2008 17:36
Vastaanottaja: Christer Holmberg; Jonathan Rosenberg
Kopio: [email-masked]
Aihe: RE: [Sip] draft-rosenberg-sip-target-uri-delivery-00.txt: P-Called-Party-ID

Mary. 

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

Hi,

Regards,

Christer

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 13 Nov 2008 19:39:23 -0600

Sorry, I misunderstood your point - your email suggests to add text about why P-Called-Party-ID was used (and didn't say "NOT used"). It's also not clear in your previous doc as you mention that 3GPP will continue to use the P-Called-Party-ID. 

Either way, I still don't think we should discuss p-headers in a standard's track document. I think Jonathan has put forth reasonable use cases that show why the solution in this document works and in general, I don't think we need to consider P-headers to solve general problems. 

ISTM you might want a 3GPP specific doc describing why this document is preferred over a solution that uses P-Called-Party-ID.

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Thursday, November 13, 2008 5:15 PM
To: Barnes, Mary (RICH2:AR00); Jonathan Rosenberg
Cc: [email-masked]
Subject: VS: [Sip] draft-rosenberg-sip-target-uri-delivery-00.txt: P-Called-Party-ID

Hi Mary,

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Mary Barnes [mailto:[email-masked]]
Lähetetty: to 13.11.2008 17:36
Vastaanottaja: Christer Holmberg; Jonathan Rosenberg
Kopio: [email-masked]
Aihe: RE: [Sip] draft-rosenberg-sip-target-uri-delivery-00.txt: P-Called-Party-ID
 
I guess I might be dense, but why can't that be derived from the HI entry just before the one marked as the "target" entry?  This was the whole concept behind capturing complete history info - you should always have the previous request URI and you can build a complete tree of the retargeting (where RFC 4244 defined that term to include both basic routing changes to the request URI as well as redirections).

Also, I don't think it's appropriate that it would even be defined in this doc, even if you need it. You would need a separate doc in SIPPING and go through the normal expert review process.

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Friday, October 31, 2008 7:52 AM
To: Jonathan Rosenberg
Cc: [email-masked]
Subject: [Sip] draft-rosenberg-sip-target-uri-delivery-00.txt:
P-Called-Party-ID

Hi,

The draft-holmberg-sip-target-uri-delivery-01.txt draft contained text on why the P-Called-Party-ID header was used. Would it be a good idea to keep that text in this spec, because I have already received questions regarding that.

Regards,

Christer

_______________________________________________
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: "Christer Holmberg" <[email-masked]>
Date: Fri, 14 Nov 2008 04:28:00 +0100

Hi Mary, 

>Sorry, I misunderstood your point - your email suggests to add text about why P-Called-Party-ID was used (and didn't say 
>"NOT used").

Ok, sorry for that.

>It's also not clear in your previous doc as you mention that 3GPP will continue to use the P-Called-Party-ID. 

Yes, but that doesn't prevent them from using the H-I mechanism, should there be a requirement for that.

P-CPI is used for another purpose than the problem we are trying to solve.

>Either way, I still don't think we should discuss p-headers in a standard's track document. I think Jonathan has put 
>forth reasonable use cases that show why the solution in this document works and in general, I don't think we need to 
>consider P-headers to solve general problems. 

I don't see a reason why we can't indicate why a specific mechanism can not be used. That is part of the justification of the new H-I mechanism.

>ISTM you might want a 3GPP specific doc describing why this document is preferred over a solution that uses P-Called-

Again, P-CPI cannot be used :)

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Thursday, November 13, 2008 5:15 PM
To: Barnes, Mary (RICH2:AR00); Jonathan Rosenberg
Cc: [email-masked]
Subject: VS: [Sip] draft-rosenberg-sip-target-uri-delivery-00.txt: P-Called-Party-ID

Hi Mary,

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Mary Barnes [mailto:[email-masked]]
Lähetetty: to 13.11.2008 17:36
Vastaanottaja: Christer Holmberg; Jonathan Rosenberg
Kopio: [email-masked]
Aihe: RE: [Sip] draft-rosenberg-sip-target-uri-delivery-00.txt: P-Called-Party-ID

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Friday, October 31, 2008 7:52 AM
To: Jonathan Rosenberg
Cc: [email-masked]
Subject: [Sip] draft-rosenberg-sip-target-uri-delivery-00.txt:
P-Called-Party-ID

Hi,

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 14 Nov 2008 13:44:12 -0600

I like this draft. It's exactly what I had in mind.

One comment however.

The name "target" is defined by this spec as a new History-Info parameter. However, the name 
"target" is also used by RFC 4458 as a SIP/SIP URI parameter.

Now, as described in RFC 4458, History-Info may capture the SIP URIs (including that parameter),
so you would endup with the term "target" twice (for different meanings) in the same History-Info,
which could be confusing.

Taking the example in 6.4/RFC 4458 for example, and adjusting it for draft-rosenberg-sip-target-uri-delivery would result in this:

    History-Info: <sip:[email-masked];user=phone >;index=1;target,
                  <sip:[email-masked]?Reason=SIP%3Bcause%3D302;\
                   text="Moved Temporarily">;index=1.1
                  <sip: [email-masked];\
                   target=sip:+15555551002%40example.com;user=phone;\
                   cause=486>;index=2;target

Now, it's parsable, but slightly confusing to have both a URI parameter and a History-Infor header 
parameter that are the same in the same history header. That would argue for a different name. (And the target in RFC 4458 is the previous target as opposed to the current target).

However...

There is another possibility. Jonathan's draft actually make the "target" URI parameter in 4458 redundant. The only thing that remains useful from 4458 is then the "cause" URI parameter.

So, we could obsolete the draft (or at least just the taget parameter in 4458). The History-Info 
heade in the previous example would look like this:

    History-Info: <sip:[email-masked];user=phone >;index=1;target,
                  <sip:[email-masked]?Reason=SIP%3Bcause%3D302;\
                   text="Moved Temporarily">;index=1.1
                  <sip: [email-masked]>;index=2;target

Comments?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 Nov 2008 17:26:36 -0500

Actually I removed the 800 use case because it doesn't work so well with 
the proposed mechanism. The reason is that, this draft is very crisp 
about how you determine if a URI is a 'target' or not - based on a 
REGISTRATION. However, for 8xx numbers, my assumption is that they would 
typically be translated to a non-8xx number by some other configured 
translation on the server, not via a registration.

For example, a server might have a config like this:

1-800-555-1212:
   replace with: [email-masked]

and then individual UAs register as 'directory'.

In reality this was a problem in the UA loose route draft too; its 
really hard to programatically determine that something is a target vs. 
not a target.

-Jonathan R.

Shida Schubert wrote:
> 
> Jonathan;
> 
>  Thanks for writing up the draft.
> 
>  There was a use-case for freephone number mentioned in section 2.7 of
> loose-route draft which no longer exists in this draft.
> 
>  I do recall that in section 2.7 of loose-route you expressed that 
> freephone
> number is just another form of alias, so I am assuming that is the reason
> you removed the text OR was there any technical reason why you removed
> the use-case?
> 
>  If there is no technical reason behind removing the text, could you
> add its use for freephone number as a use-case either as a separate
> sub-section or as part of alias use-case..
> 
>  Thanks & Regards
>   Shida
> 
> On 27-Oct-08, at 1:30 PM, [email-masked] wrote:
> 
>> 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-delivery-00.txt 
>>
>>
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 Nov 2008 17:36:16 -0500

Added. However, I must say I remain confused about handling of loose 
routes and H-I. In my example, the request will go from H-B to OB-B due 
to a route learned via a Path header field in a REGISTER. As such, that 
request should also contain a Route header pointing to OB-B. What would 
H-I look like in that case?

-Jonathan R.

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 14 Nov 2008 17:10:19 -0600

If the request-URI doesn't change, then there is no H-I entry added. 

Or am I missing your question?

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Friday, November 14, 2008 14:36
> To: Audet, Francois (SC100:3055)
> Cc: Shida Schubert; [email-masked]; Christer Holmberg (JO/LMF)
> Subject: Re: [Sip] 
> Added. However, I must say I remain confused about handling 
> of loose routes and H-I. In my example, the request will go 
> from H-B to OB-B due to a route learned via a Path header 
> field in a REGISTER. As such, that request should also 
> contain a Route header pointing to OB-B. What would H-I look 
> like in that case?
> 
> -Jonathan R.
> 
> Francois Audet wrote:
> > Actually, I think what you see in the call flow is not the 
> last leg, 
> > but the one before (i.e. to OB-B).
> > 
> >> Shida Schubert
> >>>>> 	Filename        : 
> draft-rosenberg-sip-target-uri-delivery-00.txt
> >>>>> 	Pages           : 12
> >>>>> 	Date            : 2008-10-26
> >>>>>

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 14 Nov 2008 17:58:02 -0600

The following note is in section 4.3.3.1 in RFC 4244 wrt loose routing:
   "Note that in
   the case of loose routing, the Request-URI does not change during the
   forwarding of a Request; thus, the capturing of History-Info for such
   a request would result in duplicate Request-URIs with different
   indices. "

So, basically, if you do loose routing, you don't get much value with
H-I, but there is no change in behavior for capturing H-I entries in the
case of loose routing -i.e. H-I doesn't look to see that you're doing
loose routing and not capture entries. 

Mary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Audet, Francois (SC100:3055)
Sent: Friday, November 14, 2008 5:10 PM
To: Jonathan Rosenberg
Cc: [email-masked]; Christer Holmberg (JO/LMF)
Subject: Re: [Sip] draft-rosenberg-sip-target-uri-delivery-00.txt:
P-Called-Party-ID

> routes and H-I. In my example, the request will go from H-B to OB-B 
> due to a route learned via a Path header field in a REGISTER. As such,

> that request should also contain a Route header pointing to OB-B. What

> would H-I look like in that case?
> 
> -Jonathan R.
> 
> Francois Audet wrote:

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 14 Nov 2008 18:05:48 -0600

Well, you do get value out of H-I, but only if there is 
retargeting. 

> From: Barnes, Mary (RICH2:AR00) 
> Sent: Friday, November 14, 2008 15:58
> To: Audet, Francois (SC100:3055); Jonathan Rosenberg
> Subject: RE: [Sip] 
> So, basically, if you do loose routing, you don't get much 
> value with H-I, but there is no change in behavior for 
> capturing H-I entries in the case of loose routing -i.e. H-I 
> doesn't look to see that you're doing loose routing and not 
> capture entries. 
> 
> Mary
> 
> Behalf Of Audet, Francois (SC100:3055)
> of loose

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 14 Nov 2008 18:03:06 -0600

Yes.

-----Original Message-----
From: Audet, Francois (SC100:3055) 
Sent: Friday, November 14, 2008 6:06 PM
To: Barnes, Mary (RICH2:AR00); 'Jonathan Rosenberg'
Cc: [email-masked]'; 'Christer Holmberg (JO/LMF)'
Subject: RE: [Sip] draft-rosenberg-sip-target-uri-delivery-00.txt:
P-Called-Party-ID

Well, you do get value out of H-I, but only if there is retargeting. 

> H-I, but there is no change in behavior for capturing H-I entries in 
> the case of loose routing -i.e. H-I doesn't look to see that you're 
> doing loose routing and not capture entries.
> 
> Mary
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 14 Nov 2008 18:08:50 -0600

And also value for "the last hop" (which is not using loose route, which
is the whole
point and why Jonathan had frame this problem this way in is loose-route
draft). 

> Sent: Friday, November 14, 2008 16:03
> To: Audet, Francois (SC100:3055); 'Jonathan Rosenberg'
> >    the case of loose routing, the Request-URI does not 
> change during 
> > the
> value with

---

From: Shida Schubert <[email-masked]>
Date: Sat, 15 Nov 2008 09:55:07 +0900

Hi Jonathan;

  I think when I was reading conditions in section 5.1,I understood
that  it meant if one of the condition is met "target" would be
added, which would have left room for 800 use cases based on
static configuration as you mentioned below.

  But I really don't see how it would differ whether the mapping is
configured through REGISTRATION or not.

  For example the mapping below can be configured through
registration(UA registering to directory and directory registering
to 1-800 number), in which case it will result in 2 H-I entry with
"target" parameters according to the specification(If both proxies
that does the translation supports this specification)...

  I guess I don't really see the reason why the text has to be so
restrictive.

  Regards
   Shida

On 15-Nov-08, at 7:26 AM, Jonathan Rosenberg wrote:

> Actually I removed the 800 use case because it doesn't work so well  
> with the proposed mechanism. The reason is that, this draft is very  
> crisp about how you determine if a URI is a 'target' or not - based  
> on a REGISTRATION. However, for 8xx numbers, my assumption is that  
> they would typically be translated to a non-8xx number by some other  
> configured translation on the server, not via a registration.
>
> really hard to programatically determine that something is a target  
> vs. not a target.
>
> -Jonathan R.
>
>
> Shida Schubert wrote:
>> Jonathan;

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sun, 16 Nov 2008 02:45:33 +0100

And what would be your analysis of any backwards compatibility issues?

regards

Keith

> Behalf Of Francois Audet
> Sent: Friday, November 14, 2008 7:44 PM
> To: Shida Schubert; Jonathan Rosenberg
> draft-rosenberg-sip-target-uri-delivery-00.txt:P-Called-Party-ID
> 
> The name "target" is defined by this spec as a new 
> History-Info parameter. However, the name "target" is also 
> used by RFC 4458 as a SIP/SIP URI parameter.
> 
> Now, as described in RFC 4458, History-Info may capture the 
> SIP URIs (including that parameter), so you would endup with 
> the term "target" twice (for different meanings) in the same 
> History-Info, which could be confusing.
> 
> Taking the example in 6.4/RFC 4458 for example, and adjusting 
> it for draft-rosenberg-sip-target-uri-delivery would result in this:
> 
>     History-Info: <sip:[email-masked];user=phone 
> >;index=1;target,
> Now, it's parsable, but slightly confusing to have both a URI 
> parameter and a History-Infor header parameter that are the 
> same in the same history header. That would argue for a 
> different name. (And the target in RFC 4458 is the previous 
> target as opposed to the current target).
> 
> However...
> 
> There is another possibility. Jonathan's draft actually make 
> the "target" URI parameter in 4458 redundant. The only thing 
> that remains useful from 4458 is then the "cause" URI parameter.
> 
> So, we could obsolete the draft (or at least just the taget 
> parameter in 4458). The History-Info heade in the previous 
> example would look like this:
> 
>     History-Info: <sip:[email-masked];user=phone 
> >;index=1;target,

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sun, 16 Nov 2008 02:41:54 +0100

I believe the 800 use case is still a valid problem that has to be
solved.

Do we have another way of using History-Info that would cover this
specific case. For example, do we just need an extension to the
Voicemail URI RFC?

regards

Keith 

> Behalf Of Jonathan Rosenberg
> Sent: Friday, November 14, 2008 10:27 PM
> To: Shida Schubert
> Cc: [email-masked] List
> Subject: Re: [Sip] I-D 
> Action:draft-rosenberg-sip-target-uri-delivery-00.txt
> 
> Actually I removed the 800 use case because it doesn't work 
> so well with the proposed mechanism. The reason is that, this 
> draft is very crisp about how you determine if a URI is a 
> 'target' or not - based on a REGISTRATION. However, for 8xx 
> numbers, my assumption is that they would typically be 
> translated to a non-8xx number by some other configured 
> In reality this was a problem in the UA loose route draft 
> too; its really hard to programatically determine that 
> something is a target vs. 
> not a target.
> 
> -Jonathan R.
> 
> 
> Shida Schubert wrote:
> > 
> > Jonathan;
> > 
> > freephone number is just another form of alias, so I am 
> assuming that 
> > is the reason you removed the text OR was there any 
> technical reason 
> > why you removed the use-case?
> >

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 15 Nov 2008 19:18:46 -0800

I don't know of any implementation of RFC 4458.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 16 Nov 2008 11:12:57 -0500

No, I think we'd need to allow for configuration to be a valid use case 
for addition of the target parameter as well. Shida makes a fine point 
and there is no reason to exclude it.

-Jonathan R.