Subject: [SIP] New version of message waiting draft

From: Rohan Mahy <[email-masked]>
Date: Wed, 07 Feb 2001 08:26:16 -0800

Hi,

I just finished a new version of the message waiting draft from Ilya Slain
and I.  Until it appears in the archives it is available at:

	ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-message-waiting-01.txt

thanks,
-rohan 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: "Eric Burger" <[email-masked]>
Date: Sat, 10 Feb 2001 21:35:17 -0500

[First of all, I suggest any follow-up to go to the sip-events list!!!]

Much better than the last version!

Conceptually, what we try to achieve with MWI is the _presence_ of messages
on the messaging server, much in the same way as we look for the _presence_
of people on an instant messaging system.  This philosophy doesn't change
anything in the draft, but including some sort of language to that effect
would make it more accessible to the reader.

On a behavioral level, I understand why the notification entity sends
message A13 in response to the unsubscribe request A11.  However, the UA
really doesn't want this information.  I was thinking of how to do an
unsubscribe, without either messing up the semantics of SUBSCRIBE or
creating a new method.

How about if the unsubscribe message A11 did NOT include the "Accept:
application/simple-message-summary" header.  Being a well-formed message,
the notifier would send a 200 OK and the session is finished.  This assumes
that "Expires: 0" in the new message A11.  I would put it in the spec that a
non-zero Expires time without an Accept header results in bizarre behavior.
Notification servers SHOULD reply with a 4xx (406?) response in this case.
Either way the session will be finished, as there's no reason for a
notification server to create a session to *not* send notifications.

Should this be part of sub/notify (S 5.1.5.3), or is it too odd?

--
- Eric