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

From: Eric Burger <[email-masked]>
Date: Tue, 5 Apr 2005 12:04:47 -0400

We also prefer (1), and, being a "legacy" event package, KPML uses the
mechanism documented in the draft.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Hisham Khartabil
> Sent: Monday, April 04, 2005 4:12 PM
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> Subject: Re: [Sip] Target-Dialog draft submitted - open issue around
> kpml, dialog package
> 
> 
> 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:
> 
> > 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
> >
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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