RE: Target-Dialog draft submitted - open issue around kpml, dialog package
Eric Burger <eburger <at> brooktrout.com>
2005-04-05 16:04:47 GMT
We also prefer (1), and, being a "legacy" event package, KPML uses the
mechanism documented in the draft.
> -----Original Message-----
> From: sip-bounces <at> ietf.org [mailto:sip-bounces <at> ietf.org]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
> 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
> > 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
> > 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
> > jdrosen <at> cisco.com 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 sip-implementors <at> cs.columbia.edu for questions on current sip
> > Use sipping <at> ietf.org 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 sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sipping <at> ietf.org 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 sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip