Subject: [dispatch] update Referred-by header : item proposal and charter

From: Salvatore Loreto <[email-masked]>
Date: Mon, 16 May 2011 16:54:47 +0300

Mary, Cullen and WG members,

this is a notification to propose as a new possible item for dispatch:
the update of Referred-by header

below there is also a first tentative of charter proposal for a wg
to work on updating the  Referred-by header.
http://tools.ietf.org/html/draft-loreto-dispatch-3892bis-02

Thoughts and comments on the charter proposal are appreciate.

ciao
/Sal

Charter Proposal (version 1)

Possible WG Names: Open for ideas

SIP uses the Referred-By (RFC3892) header field for conveying the identity of a REFER request.
This header field may be used when exploding a SIP MESSAGE or a SIP INVITE request to an ad-hoc or pre-defined group URI.
The Referred-By header is only included if the P-Asserted-Identify header field (RFC3325) or From header field needs to carry
another value (e.g. the pre-defined group URI, or a conference focus URI). In those cases, the Referred-By header field in the
resulting is set to the P-Asserted-Identity header field or to the From header field of the original SIP request received before
exploding so as to convey to the receiver the identity of the original inviting sender.
However Referred-by header as defined in RFC3892 restricts the value of the header to only one SIP URI. RFC5876 instead allows
the P-Asserted-Identity to contain two or more URIs, that can be SIP/SIPS URI or TEL URI.

This Working group will work on updating RFC3892 by allowing a Referred-by header to contain two or more URIs as defined
for P-Asserted-Identity header field in (RFC5876).

Deliverables

March 2012    Updates to Referred-by to IESG.

-- 
Salvatore Loreto
www.sloreto.com

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 19 May 2011 08:08:21 -0600

> http://tools.ietf.org/html/draft-loreto-dispatch-3892bis-02

It's been a long time since I looked the message exploder stuff. So A sends a message to the exploder, called E, that explodes it to B.  If A had a PAI with with a sip and tel URI it sent to E. Now the message from E to B is going to have some stuff in it but the goal is that if B supports sip URIs, a return message would go to E, but if B only support tel URI then the return message would go to A. Did I get this about right? (and by return message I mean a new out of dialog request). 

I can get my head around the requirement for E to massacred as A, or for E to show up as E, but I have a hard time seeing how B is going to have a good user experience if E tries to do both at the same time. I'm sure you have considered the option of the E sends the same PAI as it received from A. I seem to recall that is what the message exploder RFC says to do in the case the PAI is trusted. 

Don't take this wrong way - I'm not saying there is no problem here - I'm just not understanding the use case that leads to it and what the type of behavior on the B would be needed to make it all work. 

I'm also not clear if fixing this is need to update things like RFC5365 or just be a new RFC -  I was sort of surprised your draft did not reference the 5363 group of stuff as it seem it is proposing an extension to theses - it would be good to get some feedback on that for sorting out the charter. 

I think it would also be worth thinking about requirements around backwards compatibility with existing UA. If B in the example above receives an SIP message that is not consistent with the 3261 ABNF, it very well may discard the whole message. A SIP firewall may do the same. 

Cullen, in my individual contributor role

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 26 May 2011 11:34:56 +0300

Hi Cullen,

thanks for your comments see my answers in line

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

> It's been a long time since I looked the message exploder stuff. So A sends a message to the exploder, called E, that explodes it to B.  If A had a PAI with with a sip and tel URI it sent to E. Now…

no, this is not what is meant.
B *always* has the choice to respond back to all using the URI in the PAI,
or to respond back only to A using the URI in the Referred-By.
Having both a TEL URI and SIP URI in the Referred-By
just allows B to have the same information he would have about A as when 
he received a SIP request directly from A.

> I can get my head around the requirement for E to massacred as A, or for E to show up as E, but I have a hard time seeing how B is going to have a good user experience if E tries to do both at the…

the I-D explains the cases where another value needs to go into the PAI -
for example: if a URI has been defined for a pre-defined group, then the 
PAI is set to the pre-defined group URI.

> Don't take this wrong way - I'm not saying there is no problem here - I'm just not understanding the use case that leads to it and what the type of behavior on the B would be needed to make it all…

think of a client that has a contact list of phone numbers and names 
associated with them -
when the SIP request arrives, it helps if the URI it uses to search 
through the contact list is a TEL URI

> I think it would also be worth thinking about requirements around backwards compatibility with existing UA. If B in the example above receives an SIP message that is not consistent with the 3261 AB…

to be clear,
there are use cases where you could have two Referred-By headers each 
with a different value as it is already possible for P-Asserted-Identity

so we wanted to focus on the exact RFC that needs to be updated.

It is the RFC 3892 that limits Referred-By to one URI, not the 3261 ABNF.
So we want to update RF3892.