Subject: A Rose By Any Other...

From: [email-masked] (Lawrence Conroy)
Date: Wed, 15 Sep 1999 20:09:05 +0100

Hi all,
(i) CLOSE/UNSUB/EXPIRE. I'm happy with UNSUB as it is easy to see that it
closes a particular kind of session.
On reflection, CLOSE is too generic. I feel that EXPIRE is not too good,
for the same reason - what EXPIREs?
(ii) Scott's idea on UNREG is interesting. I can see when this could be
useful (and would, perhaps, mean that REG gets slightly less overloaded
that it is at present). However, as Scott rightly says, this is one for
confctl.

(iii) One other point/plea:
Point 1 at the end of 3.5.8 (the bit that says that, if a Client has sent a
BYE, it can't subsequently send a SUB). Some people in house have asked me
"why do this"? It's a good question.

Their argument goes:
*  A Client makes a PINT service request to be carried out at 7 AM the next
morning.
*  They then realise that this is a BAD idea (maybe at 3 in the morning on
the way back from a Club) and send a BYE message to cancel the request.
*  They will want to confirm that the request really has been cancelled;
the obvious way of doing this is to send a SUB (with Expires set to 0) to
check that the status is "cancelled".
-  However, in the draft as is, this can't be done as, having sent the BYE
to their earlier INVITE, they can't send a subsequent SUB.

This seems like a GOOD argument to me, so I'd like to remove this point
from the draft.

Is this OK with everyone?

----
It seems to me that this (and changing the current BYE in setion 3.5.3.x
and point 3 of section 3.5.8 into an UNSUB) is pretty much all that's
needed (along with the bug fixes that others have raised). Let's do it!

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.