Subject: [Sipping] new draft version to extend Referred-By

From: Salvatore Loreto <[email-masked]>
Date: Mon, 02 Mar 2009 11:12:25 +0200

Hi there,

I have just submitted a new version of the draft
http://www.ietf.org/internet-drafts/draft-loreto-sipping-3892bis-01.txt

it explains the needs for the
Referred-By header to be extended to  to support more than one value:

In fact as explained in the draft the Referred-by header is normally set 
to the value contained
in the P-Asserted-Identity header field  to convey to the receiver the 
identity of the original
inviting sender.
However the P-Asserted header field currently allows two URI  values and
may be expanded in the future to carry more than two values as described 
in :
http://tools.ietf.org/id/draft-ietf-sipping-update-pai-09.txt
 
cheers
Sal

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 02 Mar 2009 16:12:17 -0500

> http://tools.ietf.org/id/draft-ietf-sipping-update-pai-09.txt

I notice that section 5 of 3982bis states "There may be one or two
Referred-By values.  If there is one value, it MUST be a sip, sips, or
tel URI.  If there are two values, one value MUST be a sip or sips URI
and the other MUST be a tel URI."  This duplicates the current
restriction on P-Asserted-Identity, which as you note may be changed
soon.  Why not change that statement to something more general, so that
3892bis doesn't need to be modified track every change to
P-Asserted-Identity, etc.?

Dale

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 03 Mar 2009 09:09:20 +0200

Hi Dale,

thanks for your suggestion, in the next version of the draft I'll 
generalize that statement
so to make the 3892bis more "independent" from modification in the 
current work on
P-Asserted-Identity.

/Sal

<snip>

---

From: "Leis, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 4 Mar 2009 13:56:14 +0100

hello,

some comments on your draft.

on 4.1 Referrer Behaviour
this clause is called Referrer Behaviour. However, in the context of
RFC3892, the Referrer is the entitiy sending out a REFER request. Later
on you seem to speak of a different entity (exploder server). So the
title of this clause should change to something like "Referred-By
handling"

In addition, I believe, you could also cover the case, where a Referrer
does include Referred-by in the RERFER request and wants to include more
than one SIP URI in the Referred-By header field. I guess this should be
possible using your draft.
   
Would be good to be more specific as to what "if privacy was requested"
means. Something like "if privacy was request using a Privacy header
field with value 'id' " 

on 4.2 "General handling"
the title of this clause could be more specific. Although being called
"general", you seem to describe handling of "unexpected cases"

regards
Peter   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Salvatore Loreto
Sent: Monday, March 02, 2009 10:12 AM
To: sipping
Cc: Nadia Bishai; [email-masked]
Subject: [Sipping] new draft version to extend Referred-By

Hi there,

to the value contained

in :
 
cheers
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: Salvatore Loreto <[email-masked]>
Date: Fri, 06 Mar 2009 11:02:52 +0200

Hi there,

I have just submitted a new version of the draft
http://tools.ietf.org/id/draft-loreto-sipping-context-id-requirements-02.txt

It now includes use cases and requirements to correlate dialogs that
*may or may not* be related to the same multimedia session.
So it now includes also discussion on the rationale to correlate
an incoming with an outgoing dialog at a B2BUA, as explained already in
Hadriel draft: 
http://www.ietf.org/internet-drafts/draft-kaplan-sip-session-id-01.txt

The requirement are divided in three parts:
- Media Session correlation
- Dialog correlation
- Common requirements

The section on "Existing mechanisms" now include also 3pcc, as a possible
mechanism to address some of the requirements, and outlines the pro and cons
of 3pcc vs a "correlate mechanism"

comments are welcome

cheers
Sal

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 09 Mar 2009 12:25:10 +0200

Hi Peter,

thanks for the comments, see answers in line

best regards
Sal

> title of this clause should change to something like "Referred-By
[Sal] yes, you are right, in the next version we will change the title 
as you proposed in "Referred-by handling"
> possible using your draft.
[Sal] well we are extending the Referred-By header definition to support 
more than one SIP URI,
so yes it would be possible for a user to insert in the Referred-by 
header of a REFER request more
then one SIP URI.
I don't know if it is necessary to explicit it. what do you think?

> means. Something like "if privacy was request using a Privacy header
[Sal] we will reword the statement to be more specific here.
> "general", you seem to describe handling of "unexpected cases"
[Sal] That's a correct observation, this section handles error cases 
when more than one URI is received
so we will change the title to "Hanlding of unexepected cases".