Subject: [lemonade] Server To Server notification protocol requirements

From: Decktor Gev <[email-masked]>
Date: Tue, 20 Jan 2004 19:00:52 +0200

Hi all,

basically the points raised in the 58th IETF in the matter of server to
server notification protocol requirements, could be divided into 2 main
categories:

1. missing/inaccurate requirements details in the document as is
2. why not use XMPP as the answer for these requirements.

XMPP's scope is IM, meaning two end point sending each other "small, simple
messages that are delivered immediately to online users"(RFC2779). On the
other hand Server to Server Messaging Notification (S2SMN), refers to a
entity, which defines in an offline manner when and how it would like to be
notified upon mailbox events. The entities, which have triggered the event
aren't taking an active part in this scenario.

This means that the notification event initiator (e.g. voice mail server)
will send event about mailbox status change and the notification service
will be responsible for deciding what to do with that information, how and
when (i.e. the subscriber's notification preferences).

In the IM world, the voice mail server from the previous example, would have
to "know" the subscriber's notification preferences. As a result the
notification service's functionality would diminish to being a gateway to
non XMPP networks. 

This implies that any server which wishes to participate in this scenario,
would have to "know" the subscriber's notification preferences as well AND
there won't be a single notification logics entity (which would result
different notification "look And Feel" for each message store (email
messages Vs. Voice messages))

S2SMN is the problem described in part 6.3 of the lemonade goals
draft(http://www.ietf.org/internet-drafts/draft-ietf-lemonade-goals-01.txt),
not IM (although there may be many similarities).

To sum up,
XMPP would be regarded as a valid option for implementing the server to
server notification protocol, yet this decision should be taken after
agreeing on the requirements. These requirements should not be derived from
existing protocols, but rather from the needed functionality as described in
the charter.

Regarding the feedbacks in the LEMONADE meeting itself, I intend to adapt
the draft to answer to all of them. A new edition of the draft would be sent
in the next week.

Please, 
share you thoughts with me
Thanx,
Gev.