Subject: Still Pushing towards closure

From: [email-masked] (Lawrence Conroy)
Date: Fri, 10 Sep 1999 20:38:44 +0100

Hi Folks,

* Re Henning's proposal for a new method:
I agree; a new method to indicate closure of a monitoring session works well.
Let's call it "CLOSE".
It will be to monitoring sessions what BYE is to INVITE sessions.

* Re. Henning's subtle suggestion that the monitoring session should not
depend on an INVITE/BYE call:
This (I think) is where we were going. SUB/NOT may be used elsewhere, of
course, so we don't really want to make life more difficult for others than
just a "cut-and-paste" job.

In the PINT 1.0 case I believe that the monitoring session will be
"targeted" at a service session started by a prior INVITE, so in our
specific case the SUB will identify the object of interest by an SDP body
(as used in the earlier INVITE that opened the service session).

IMHO, if there IS an SDP body part included in a SUB message, then it
should be used as a correlator or specifier for the object of interest.
In the PINT case, there will be, so that's sufficient.
In the more general (non-PINT) case, a non-SDP body part could specify the
items of interest in other ways (e.g. by plain text or XML body part
containing a list of values, perhaps?), but that's out of scope for today.

Similarly, the "short cut" that Scott proposed (that a client could send an
INVITE, then a SUB, and then a BYE to mean that both the service request
was rescinded and that the monitoring session was to end) ties the
monitoring session to the BYE. For complete separation, the client should
send a "CLOSE" message and a separate "BYE" message.

I'm inclined to leave in this short cut, for the PINT case where the
monitoring session requested by the INVITEr is tied closely to its earlier
service request.
It simplifies what is a common case and it's in the current draft.
Opinions?

As for short cuts, I'm also inclined to leave in the Subscribe with
Expires=0 method, meaning "send me a single NOTIFY and then close the
monitoring session".
It's in the draft already. After this long exchange I hope we all agree
that this can be done as a Re-SUB, so shortening an existing monitoring
session; the draft remains the same.
Opinions?

With Henning's proposal it's just a case of changing "BYE" to "CLOSE"
(almost) throughout section 3.5.3, removing the last paragraph of section
3.5.8, and tidying up with the innumerable bugs/features that Bernie and
others have exposed.

I like this idea a lot; we might even be able to put PINT to bed?

All the best, Lawrence
-----------------------------------------------------------------------
| Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
| Roke Manor Research |  were my Company's they'd charge you for them"|
|- [email-masked]  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|

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

---

From: Scott Petrack <[email-masked]>
Date: Mon, 13 Sep 1999 12:41:35 -0400 (EDT)

A few tiny nits:

1) I would vastly prefer to call the new method EXPIRED, or something
similar. The reason is two-fold:

	a) CLOSE is just too generic for my taste. I can't really tell by
its name what it's good for. If you counter that BYE is also generic, I
would say "exactly", and look at the trouble it caused because of that.

	b) EXPIRED is exactly the meaning -- a request which was
previously accepted with some Expires time has now had its Expires time
changed. In fact, if you wanted to do something truly generic, we could
call the method CHANGED and have it indicate that the recipient of some
previous request now intends to pretend that the former request had some
different parameters in it. But I fear that this will get us into some bad
bad waters, so I'm happy to leave it as "EXPIRED" with meaning that
whatever the former expiration time was, it is now 0. 

	Personally, I might use this method for REGISTER as well, to tell
a client that it is being unregistered. 

2) Forgive me, but I thought that we agreed that the successful response
to a SUBSCRIBE contains the first notification within its body. Therefore,
a SUBSCRIBE with Expires:0 normally will just return an OK response with a
body, and that's it -- no NOTIFY. An exception would be if it had a
Contact: field, in which case I suppose you should send a single NOTIFY to
the Contact: address.

I won't die if you all insist that at least one NOTIFY be sent. But I
thought that we did it without it, in order to provide the service of
"tell me what the current status is now", with a single message and single
round-trip.

3) I agree that when a client sends an INVITE and then a SUBSCRIBE, the
server should send both a BYE and an EXPIRED (aka CLOSED). In principle,
these can appear in any order. There may well be times when there is
something to NOTIFY after the phone call is ended.

Scott

---------