Subject: Re: [Sip] Refer status/adjustment

From: "Daniel G. Petrie" <[email-masked]>
Date: Tue, 25 Jun 2002 00:59:05 -0400

The following comments pertain to
draft-sparks-sip-refer-3265disc-00.txt

Overall I think this draft is mostly harmless.  I think that it is
good to make things consistant with the latest SIP events.
On the other hand there are a lot of small changes for
not much functionaly increase.  My major concern relates
to the existing installed base implemented on prior drafts
of REFER.  There is a significant installed base of
products and services that depend upon prior versions
of the REFER draft.  There are some upward compatability
issues in the changes proposed in this draft.  Some mostly
minor comments are included below.

I assume the rules for name-addr vs. addr-spec from RFC3261 apply
in the same way.  That is in the Refer-To header examples that
have ? followed by header parameters, the name-addr form should
be used with angle brackets.

Ignoring the installed base I have no technical issues with the use of
the referevent token to indicate the desire for notification of outcome.

However, in the real world this presents an upward compatability
issue.  If the transferor is a prior refer-3261 implementation, it
will not send the referevent token in the Supported header.  If
the transferee is a post refer-3261 implementation it will not
send a notify and the transferor will wait a long time for the
NOTIFY request and at best give a false indication of transfer
failure. It is a little ugly, but reversing the sense is upward
compatable (e.g. noreferevent token).

It seems that last paragraph in section 2.4.2 gives the REFER
recipient the choice of whether it wants to send a NOTIFY
event or not.  I am not sure if I object to this or not, but
is there a reason or example of why this is useful? It does
make things a little more complicated in that there are
more possible outcomes (there is no shortage of error
cases even without this possibility).

2.4.3  I think there is a possible race condition here.  Though
the possiblity is remote the user agent sending the REFER
request should be prepared to receive the NOTIFY prior
to the 2xx response to the REFER.  Oh I see that is pointed
out in 2.4.5

2.5.6 Is it not valid to send any provisional response  in the
sipfrag body (e.g. 180) when the subscription state is pending?

Cheers,
Dan

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: 25 Jun 2002 10:17:02 -0500

> be used with angle brackets.
Yes.
> compatable (e.g. noreferevent token).

That just moves the compatibility shoe to another foot.
Taking this route you step back into the mess of something that
wants notification having no way to know whether its going to
get it or not until after the first notify arrives.

> cases even without this possibility).

Well, if it didn't have that choice, we wouldn't have the
problems motivating this referevent token at all. 

The choice exists exactly to allow elements to accept REFER but
not create a subscription. Those arguing for it claim that events
is to heavy to require its implementation (think _way_ back to the
rather intense discussions we had on this at the Feb 2001 interim).

> sipfrag body (e.g. 180) when the subscription state is pending?

If the subscription state is pending, the notifications carry a 
"nuetral" state. 100 fits that bill nicely. How were you seeing using
18x's? To carry information about the progress of obtaining
authorization for the subscription? That information should go
into the subscription-state header or somewhere else, but not in
this body. This body carries the state of the referred event.

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Wed, 26 Jun 2002 18:20:57 -0400

Coments below:

> > draft-sparks-sip-refer-3265disc-00.txt

...

> get it or not until after the first notify arrives.

Sorry I may have missed something in your point.  Let me clarify
what I was suggesting to make sure that is not the problem.  In prior
REFER drafts it was assumed that the NOTIFY was manditory.
Even so, a robust implementation which is tolerent of error
conditions MUST tolerate the case where the NOTIFY never
gets delivered (e.g. due to network failures).  Otherwise your
user agent hangs forever waiting for a NOTIFY that dropped
on the floor.  With or without the Supported token in either
sense this is necessary.

My suggestion was to make the implied subscription the
default (I think that you will find that most existing
implementations do this.).  Then use the Supported token
(e.g. noreferevent) as a way to say that a subscription is
not desired.  This way the risk of interoperability is that
a UA gets an implied subscription that it does not want.
This is easily solved with a 481 response or worst
case just ignored.

On the server side of the REFER, a server which does
not implement the subscription SHOULD either send
an error if the noreferevent tag is not present or it
SHOULD send a single immediate NOTIFY indicating
the subscription is terminated.  This is fairly light weight
as the full subscription framework is not needed only
a trivial NOTIFY.  It also does not require any
subscription state (which I am guessing is the major
objection to events being too heavy weight to
implement in this case).  The NOTIFY should
probably have either a 180 or failure code.

So the assumtion is that a UA sending a REFER will
receive a NOTIFY unless the noreferevent token is
present.   This is the source of my confusion with your
statement above.

> rather intense discussions we had on this at the Feb 2001 interim).

I have been poking through the list trying to find a more recent
discussion of this requirement without much luck.  Could you point
me at the dates of some message. I guess that in pursuing the NOTIFY
solution we had concluded that it was ok to require events. I am still
wondering
if this is a requirement we really need to satisfy.  I worry about
interoperability
(of implementation of this draft, not different versions of the refer draft)
with this requirement.  If events support is not required or at  least a
SHOULD you end up bringing the whole experience down to a
lowest common denominator.  It ends up making both solutions
(with and without events) more complicated in terms of error
cases that can occur.

I appologize if this was already discussed recently on the list.  I guess I
find the claim that events is too heavy weight to be a weak
rational.  I disagree with the requirement to make events optional.

> this body. This body carries the state of the referred event.

Ignore the 18x issue.  My mistake. Sorry.

---

From: Robert Sparks <[email-masked]>
Date: 27 Jun 2002 09:35:06 -0500

> REFER drafts it was assumed that the NOTIFY was manditory.

No, it wasn't. That's probably where our disconnect was. This
was made optional when we first decided to go with implicit
subscriptions.

> This is easily solved with a 481 response or worst

And you have a similar compatibility issue as motivates
your concern. There may be existing systems out there
that don't create subscriptions. They won't look for
a noreferevent token. As a client, you would really
have no way to know whether or not you are going to
get a NOTIFY until one shows up.

> lowest common denominator.  It ends up making both solutions
It is and has been SHOULD, but even so, it forces you to code those
peers that believe they have good reason not to play.
> rational.  I disagree with the requirement to make events optional.

Well, as I said before, that is a _very_ old decision, made when we
first brought in subscriptions to get around the finite-length
non-INVITE transaction. I don't believe it has been revisited on the
list since. 

As I said above, if we had been able to make participation in this
subscription a MUST, none of the problems motivating the referevent
token would exist. The draft would be much simpler. I believe 
implementations would be simpler, even if it did mean bringing in
event handling code (the simple "I refuse to accept any subscriptions"
implementation you describe above points out that this is not that
heavy a burden.

I am very hesitant to reopen yet another decision. But it would be
useful to know if the original proponents (or anybody else) of making
sending any NOTIFYs at all optional still care. Even better, has 
anyone implemented this? If nobody speaks up to either of those points,
we could change that SHOULD to MUST and toss the referevent idea.

RjS

---

From: Robert Sparks <[email-masked]>
Date: 27 Jun 2002 09:46:23 -0500

This was part of the last message I sent, but it was buried
pretty deep.

When we made the decision to go with implicit subscriptions
work around the finite length non-INVITE transaction, we made
serving that subscription SHOULD strength to allow for implementations
that couldn't deal with the weight of serving subscriptions.

Do the original proponents of allowing implementations to never
send a notify still see this need? Are there any implementations
out there that accept a REFER but don't send NOTIFYs?

The subscription concept has substantially matured (in particular,
Subscription-State is explicitly communicated). As Dan points out
in his last note, an implementation that needed to be very lightweight
could send exactly one NOTIFY terminating the subscription. If
serving the subscription (even if it involved sending just that
one NOTIFY) were strictly mandatory, the error space is much smaller.

RjS