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

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Feb 2004 13:48:39 -0500

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.

	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.

----------

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:

- 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.

(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.

(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.

	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