Subject: [Sipping] RE: draft-olson-sipping-refer-extensions-01.txt

From: "Orit Levin" <[email-masked]>
Date: Wed, 18 Feb 2004 13:39:38 -0800

Thanks a lot for your comments!

Answers are inline,
Orit. 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, February 18, 2004 10:49 AM
To: Sean Olson; Orit Levin
Cc: [email-masked]
Subject: Re: draft-olson-sipping-refer-extensions-01.txt

Wow! You made a lot of changes in this version.

I do have a number of comments about this version, below. I think I was
happier with it before. This one seems to have run amuck.

OL: At least it draws attention and generates useful comments:-) 

	Paul

First, a nit: The introduction says:

    Finally, there are
    situations where the party issuing the REFER request does not need
    the NOTIFY associated with the REFER, perhaps because that agent is
    already subscribed to the appropriate package outside of the REFER
    request.

I agree there are situations where the referring party doesn't need the
NOTIFY, but not because it is already subscribed for it. There is no way
to independently subscribe to the refer event package.

OL: Agreed.

----------

Section 7 says:

    The REFER-Issuer MAY specify the request for subscription to a
    specific package by including the MIME type in an Accept header.

Yuk! All kinds of problems with this:

OL: I agree that it is much simpler to just suppress the implicit
subscription (and subscribe to whatever package you need independently).
From authors' perspective, it will meet our requirements. My inclination
is that we stick to this feature only if we solve all the problems
associated with it. We definitely need to work more on this part.

- event packages are not defined by mime-types, they are defined by
event package names. It is possible for several event packages to share
a mime-type for their notifications, and for multiple mime-types to be
permissible for a single event package.

- subscribing to an event package requires both the event package name
and the event id. (In the case of the special refer event package, the
event id is defined by the cseq of the REFER message itself.)

- If bundling REFER with an implicit subscription to the refer event
package was a bad idea (as most seem to think) then bundling it with the
establishment of arbitrary subscriptions is an even worse idea.

- Based on the examples, this isn't really a matter of subscribing to a
different event package. The event package named in the NOTIFY is still
"refer", but the content-type is changed. So the effect is of redefining
the refer event package so that it may return content equivalent to that
of any other event package. This is at best a kludge. It also probably
violates the rules for defining of event packages. In this model it
isn't at all clear what defines how the content of the notifies is
obtained, or when it is generated, since that is generally defined as
part of an unnamed event package.

If you really want to do this, then I think you must ammend the
definition of the refer event package to include (presumably by
reference) most of the definition of any of the other event packages
that you might want to request this way. But I still think this is a bad
idea. Even if it requires extra messages, I think subscriptions to
anthing but the refer event package should be established first, before
sending the refer.

---------

Later in that section, another nit:

    In the INVITE example, two things that are generally lacking from
the
    message/sipfrag content are the dialog identifier (Call-ID plus
local
    and remote tags) and the state of the dialog. Not coincidentally,
    this is the same information available in the application/
    dialog-info+xml MIME type [7] used for the dialog event package.

The dialog-id can be available using the sipfrag content if
refer-recipient chooses to provide them. They are available if the
fragment contains the to, from, and call-id from the invite response.

OL: Will refine the text.

(I agree that certain dialog status may not be determined via the refer
event package.)

----------

norefersub: While I think this is a good feature to support, I think it
is a stretch to encode it as a required option. That mechanism is
normally used for more general functionality that transcends a
particular request. It would be good to have a way to specify this in a
way that is more specific to refer. One alternative might be to add a
norefersub parameter to the Refer-To header.

OL: I agree. What level of support to request should be left up to the
REFER-Issuer decision.

(Also note that returning a 481 in response to the first NOTIFY may not
always be a cheap way to cancel the subscription without norefersub. If
the refer was sent within a preexisting dialog, returning a 481 to the
notify might be construed as absence of the entire dialog. If so, all
the things sharing the dialog might also be terminated. So in that case
it may be necessary to cancel by sending a subscribe with expires:0,
requiring 5 messages rather than one.)

------------

In general there seem to be far more option tags than are needed. I
think it would be sufficient to define one new option tag indicating
support for all the functionality in this draft. Requesting of specific
features can be via other parameters or headers.

OL: Yes, it is one of the issues I am going to raise in the meeting:
What level of granularity we need for these extensions.

	Paul

_______________________________________________
Sipping mailing list  https://www1.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