Subject: [Sipping] new draft loreto-sipping-3892bis

From: Salvatore Loreto <[email-masked]>
Date: Mon, 07 Jul 2008 10:40:35 +0300

Hi there,

I have just submitted a draft that explains the needs for the 
Referred-By header to be extended
to allow up to two values.

http://tools.ietf.org/id/draft-loreto-sipping-3892bis-00.txt

Abstract

   SIP has a mechanism for conveying the asserted identity of the
   originator of a request by means of the P-Asserted-Identity header
   field.  When exploding a SIP MESSAGE request to a pre-defined group
   URI and when exploding a SIP INVITE request to an ad-hoc group or to
   a pre-defined group URI, the Referred-By header field in the
   resulting exploded requests is set to the P-Asserted-Identity header
   field or to the From header field.  The Referred-By header is only
   included if the P-Asserted-Identity header field or From header field
   needs to carry another value, e.g. the URI of a pre-defined group, or
   a conference focus URI.  Since the P-Asserted-Identity header field
  may carry up to two values, the Referred-By definition needs to be
   extended to allow up to two values as well.

I'd like receive your comments, suggestion and opinion on it.
thanks
/Sal
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Nancy Greene" <[email-masked]>
Date: Fri, 11 Jul 2008 10:35:25 -0400

This is something that has come up when implementing the OMA SIMPLE IM
specs - for example, the Referred-By header carries the identity of the
originator of an exploded message that was sent to a pre-defined group
URI, and when the identity of the originator comes from the
P-Asserted-Identity and carries both a TEL URI and SIP URI, it does not
seem right to lose one of them when it is copied over to the Referred-By
header. 

It is clear that the two identities would have the same constraints as
the carrying of two identities in the P-Asserted-Identity - they would
always refer to the same originator.

Nancy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Salvatore Loreto
Sent: July 7, 2008 3:41 AM
To: SIPPING LIST
Cc: Nadia Bishai; [email-masked]
Subject: [Sipping] new draft loreto-sipping-3892bis

Hi there,

I have just submitted a draft that explains the needs for the
Referred-By header to be extended to allow up to two values.

Abstract

I'd like receive your comments, suggestion and opinion on it.
thanks
/Sal
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 14 Jul 2008 19:37:13 +0200

Given that the two identities are alias's I don't understand how you
lose one by only presenting one. But maybe this goes back to the fact
that we have not rigorously defined alias.

But addressing the draft, I don't believe the case is automatically made
that because there are two P-Asserted-Identities in an INVITE request,
there should automatically be two in the Referred-By. I would hope the
author's of the draft provide a more comprehensive use case. Remember
that the reason the second P-Asserted-Identity got added to RFC 3325 in
the first place was for interworking with a system that was unable to
use the SIP URI, i.e. the PSTN. At the moment, I am unaware of any PSTN
interworking specification that interworks the Referred-By header - but
that may just be ignorance. 

Note that I assume discussion of this document should currently be
addressing the requirements - once the requirements are addressed by
SIPPING, then RFC 3427 applies.

Regards

Keith

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nancy Greene
> Sent: Friday, July 11, 2008 3:35 PM
> To: Salvatore Loreto; SIPPING LIST
> Subject: Re: [Sipping] new draft loreto-sipping-3892bis
> 
> This is something that has come up when implementing the OMA 
> SIMPLE IM specs - for example, the Referred-By header carries 
> the identity of the originator of an exploded message that 
> was sent to a pre-defined group URI, and when the identity of 
> the originator comes from the P-Asserted-Identity and carries 
> both a TEL URI and SIP URI, it does not seem right to lose 
> one of them when it is copied over to the Referred-By header. 
> 
> It is clear that the two identities would have the same 
> constraints as the carrying of two identities in the 
> P-Asserted-Identity - they would always refer to the same originator.
> 
> Nancy 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Salvatore Loreto
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Nancy Greene" <[email-masked]>
Date: Wed, 23 Jul 2008 06:59:08 -0400

It may be that the receiving user only has stored one of the aliases in
his address book, so in order to clearly present the sender to the
receiving user, both aliases need to be available. Since they would have
both been there in the P-Asserted-Identity, they should also be both in
the Referred-By header. 

Nancy

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: July 14, 2008 1:37 PM
To: Nancy Greene; Salvatore Loreto; SIPPING LIST
Subject: RE: [Sipping] new draft loreto-sipping-3892bis

Regards

Keith

> specs - for example, the Referred-By header carries the identity of 
> the originator of an exploded message that was sent to a pre-defined 
> group URI, and when the identity of the originator comes from the 
> P-Asserted-Identity and carries both a TEL URI and SIP URI, it does 
> not seem right to lose one of them when it is copied over to the 
> Referred-By header.
>

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 23 Jul 2008 14:08:45 +0300

Hi Drage,

yes the document is currently only addressing the requirement
then we will forward to sip wg

regards
Sal