Subject: CLOSE, UNSXXSCRIBE, EXPIRE

From: Scott Petrack <[email-masked]>
Date: Tue, 14 Sep 1999 16:47:43 -0400 (EDT)

Let me try to make clear why I really don't want to call it UNSXXSCRIBE.
Don't get angry at me, I'm not trying to be a pratt, really. I have a real
point in mind.

I think that we need this message for REGISTER as well as SXXSCRIBE.
That is, I am not suggesting that we add any text to the PINT draft about
using this method (which I'll call EXPIRE if you believe it should be an
active verb (not that BYE or OPTIONS are active verbs or even verbs). I am
just saying that there is a need for such a generic method to work with
REGISTER as well as with SXXSCRIBE. The method name should not be tied to
SXXSCRIBE. 

This method means that a previous request which was accepted with a
particular Expires: value now is considered by the sender to be completely
expired. 

We seem to think that REGISTER and SXXSCRIBE follow a similar model. And
we have now identified a need to have the server which previously accepted
a request with one of these methods now say "I now consider that previous
request has expired." 

Although in the SIP spec, a server can only delete REGISTERations
silently, I have seen occasions when it would be very useful to be able
to make the unregistration explicit. 

Once upon a time, there was an UNREGISTER message, and if that message
existed, it would be clear what this means, if this were sent from
the registrar back to the original client. I'll bet that we all feel that
it would be *bad* to send a REGISTER with Expires:0 from the registrar
back to the client, just like we all feel that it would be *bad* to send a
SXXSCRIBE with Expires:0 from the server back to the client. (We already
saw that we don't like Expires:0 in the NOTIFY for this).

Bottom line -- I'd prefer to have a single message which means that a
previous request has been EXPIREd by the sender and should be EXPIREd by
the recipient. If this message had a generic name, it could be used by
either REGISTER or SXXSCRIBE. 

If people don't think that it should be generic, then I'd agree to go to
the UNSXXSCRIBE (and as a separate issue for confctrl I'd suggest that we
need an UNREGISTER too, but that's not a PINT issue).

Scott

---------
This message came from the IETF PINT Working Group Mailing List.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 15 Sep 1999 00:13:11 -0400

> need an UNREGISTER too, but that's not a PINT issue).

I like the notion of a more generic request, but there are some open
issues then. Most importantly, how does one determine what it is that is
being expired from the EXPIRED request? Do we use the Call-ID, so that
the request being cancelled is the one sent with the same Call-ID? What
if multiple requests were sent with the same Call-ID, but different
CSeq? Does the request URI somehow reflect what is being cancelled?

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---------

---

From: Scott Petrack <[email-masked]>
Date: Wed, 15 Sep 1999 18:16:13 -0400 (EDT)

Hmmm, I am having two contradictory thoughts. At the end I guess I'm going
to give in and go for UNSXXSCRIBE (although I would like an UNREGISTER
too).

1.  Possibility 1:

An endpoint should NEVER use a single call-leg to send two unrelated
requests (like first a REGISTER and then a SXXSCRIBE). call-ids are not a
scarce resource, and under the principle that call-ids should
not be used to tie together unrelated requests (like I wanted to do with
SXXSCRIBE and INVITE), you should just pick a different call-id for these
unrelated requests.

Re-using a Call-leg should only be done if you expressly wish to tie
together the request with previous requests along the same call-leg.
Examples of this are things like:

	a) Sending a new INVITE (with changed parameters) along the same
		call-leg as a previous INVITE.
	b) Sending a BYE along the same call-leg as a previous INVITE
	c) Sending a new REGISTER along the same call-leg
		as a previous REGISTER (and likewise for SXXSCRIBE).

All that being said, the question remains -- so what should happen if a
client does send two "unrelated" requests along the same call-leg?? Should
the second one be rejected? If yes, what would the error be? If it is
accepted, then I suggest that EXPIRE(D) means that ALL the previous
outstanding requests which had expiration times are now considered
expired. (If an INVITE had been previously received with a long positive
expiration time, it should be given a definitive response before any
EXPIRE(D) is sent. EXPIRE(D)s only relate to previous SXXSCRIBE or
REGISTER).

2. The other possibility is to give in, and not make a generic command,
but indeed to call it UNSXXSCRIBE, and be done with it. If we ever decided
that we need a similar method to pair with REGISTER, we'll invent one and
call it UNREGISTER.

Reviewing the preceeding, I guess that USXXSCRIBE is the safer
alternative. 

(In this case, I would suggest that SIP (not PINT) *does* need an
UNREGISTER so that the registrar can tell the client that it has been
deleted, but this is not a PINT problem.).

Scott

---------