Subject: [Sip] Target-Dialog draft submitted - open issue around kpml, dialog package

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 04 Apr 2005 03:23:49 -0400

Folks,

I've updated the target dialog draft based on discussions during IETF 
and some list comments, and submitted it. Until it appears, you can pick 
it up at:

http://www.jdrosen.net/papers/draft-ietf-sip-target-dialog-00.txt

Writing this up did pop out an open issue which we need to resolve. This 
issue might impact the dialog and kpml package drafts depending on how 
we go.

The issue is this. The target-dialog draft says to include this header 
field if you need a new request to be authorized by proving that you 
know about a specific dialog. We made this a header field so that it 
could work with REFER or SUBSCRIBE or even INVITE. With SUBSCRIBE, 
however, two of the potential event packages to use this (dialog and 
kpml), ALREADY have a means of proving that the subscriber knows the 
target dialog - through the Event header field parameters which each 
define. Thus, it would seem that including the event header field 
parameters and target-dialog header field is redundant.

I see three solutions:

1. Only include the target-dialog header field when there isn't already 
something in the message that proves you know the target dialog. The 
drawback here is that a UA seeking authorization of a request will need 
to potentially look in several places for proof of dialog awareness.

2. Include both of them. They have different semantics. The event header 
parameters are basically filters. The target-dialog header field is used 
to drive authorization. Thus, a single request will often have both 
containing the same dialog identifiers. One might imagine cases where 
they aren't the same; i.e. I subscribe using the dialog event package to 
dialog X, but authorization is based on my awareness of dialog Y.

3. Limit Target-DIalog to REFER, possibly INVITE.

(2) is more general but inefficient. (1) is more efficient, and more 
compatible with how kpml and the dialog event package work today. Going 
with approach (2) means that both documents might need to be updated; 
KPML at least probably would.

I'm inclined to go for (1), but there was ample arguments in favor of 
(1) and (2) that I wanted to bring it to the list. The target-dialog 
draft is currently written assuming solution (2), however. I'd need to 
update it if we go to (1).

I've also updated app-interaction to make usage of target dialog, but 
I'll wait to submit that until we've concluded this issue.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.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: Hisham Khartabil <[email-masked]>
Date: Mon, 4 Apr 2005 22:12:28 +0200

I prefer (1) with a slight modification: you need to say that event 
packages needing this information are required to choose which 
mechanism to use and document it. If an event package does not define a 
mechanism then the target-dialog header should be used. target-dialog 
extension must not be used with event packages the define where to 
place such info.

I don't think the drawback you mention for 1 is a drawback really. 
Implementers of an event package that already defines where to find 
target dialog information (like dialog package) would not use this 
extension and therefore recipients who also understand the package 
would not look in 2 places. The package document tells you where to 
look.

Hisham

On Apr 4, 2005, at 9:23 AM, Jonathan Rosenberg wrote:

> and some list comments, and submitted it. Until it appears, you can 
> pick it up at:
>
> Writing this up did pop out an open issue which we need to resolve. 
> This issue might impact the dialog and kpml package drafts depending 
> on how we go.
>
> 1. Only include the target-dialog header field when there isn't 
> already something in the message that proves you know the target 
> dialog. The drawback here is that a UA seeking authorization of a 
> request will need to potentially look in several places for proof of 
> dialog awareness.
>
> 2. Include both of them. They have different semantics. The event 
> header parameters are basically filters. The target-dialog header 
> field is used to drive authorization. Thus, a single request will 
> often have both containing the same dialog identifiers. One might 
> imagine cases where they aren't the same; i.e. I subscribe using the 
> dialog event package to dialog X, but authorization is based on my 
> awareness of dialog Y.
>
> compatible with how kpml and the dialog event package work today. 
> Going with approach (2) means that both documents might need to be 
> updated; KPML at least probably would.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Apr 2005 20:48:58 -0400

Hisham Khartabil wrote:

> packages needing this information are required to choose which mechanism 
> to use and document it. If an event package does not define a mechanism 
> then the target-dialog header should be used. target-dialog extension 
> must not be used with event packages the define where to place such info.

My point is that the semantics are different. The usage of the dialog 
identifiers in the event header field is more like a filter; it is 
asking the recipient for a subscription to information related to that 
dialog only. The Target-Dialog header field is used for 
proof-of-knowledge for authorization purposes. One can imagine that a 
single event package might use the dialog identifiers in the Event 
header field in some subscriptions (in which case target dialog is not 
needed), and in other cases, the event header field has no dialog 
identifiers, but still the target dialog is needed for authorization 
purposes.

> extension and therefore recipients who also understand the package would 
> not look in 2 places. The package document tells you where to look.

Per above, I don't think you could do that in many cases.

-Jonathan R.

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 6 Apr 2005 19:00:32 +0200

I'm confused now. If they serve different purposes, then what is the 
problem? Do you believe that current implementations of those mentioned 
event packages already use the event header information for 
authorisation purposes?

Hisham

On Apr 6, 2005, at 2:48 AM, Jonathan Rosenberg wrote:

>> mechanism to use and document it. If an event package does not define 
>> a mechanism then the target-dialog header should be used. 
>> target-dialog extension must not be used with event packages the 
>> define where to place such info.
>

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 6 Apr 2005 19:01:57 +0200

Hisham

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 09 Apr 2005 02:44:29 -0400

> event packages already use the event header information for 

OK, let me try to clarify.

You had proposed that each event package gets to pick what it does. You 
said they can either use target-dialog, or use something else. I dont 
think it works that way.

Target-Dialog is to provide authorization by presenting certain 
information. If that information is presented in other places, then 
target dialog is not needed.

So, an event package might need target-dialog in some flows (those where 
authorization is needed but not present in the event header or 
otherwise), and not in others. Whether its needed or not will not be 
fixed for all flows for an event package; that is my point. Within the 
same event package, sometimes it might be needed, sometimes not.

Its certainly reasonable for an event package to discuss when it might 
be needed.

Hope that clarifies,
Jonathan R.