Subject: [UM] Server-to-Server Requirements - a few comment

From: Shapira Noam <[email-masked]>
Date: Wed, 19 Mar 2003 15:47:45 +0200

Hi Lisa, all,

As Ari specified in the previous email I would like to give a few comments
on the Server-to-Server Requirements (by Lisa Dusseault).
Unfortunately - I will not be able to attend the meeting on Thursday - so
here are my comments:

There are 4 main issues I would like to relate to:
1. Connection Characteristics- is HTTP good enough?
2. Profile information / subscription issues
3. Security issues
4. Extensibility

So,

1. Connection Characteristics - is HTTP good enough?

Lisa's main requirement for the transport layer is that the protocol should
be light weight as it is going to host very high traffic (as explained in
the draft).  Further, it should support the security requirements (mentioned
later on) with minimum overhead.
The argument suggested is that HTTP is too heavy for such a task (the
overhead of HTTP information as a request/response protocol - is high and
it's necessity is questionable). I would like to suggest a different
approach - and give a few pointers in favor of HTTP - as I see it (my answer
is mostly in the context of Messaging Notification - as defined in SNAP):
A. HTTP is easy to deploy - we are using a well known protocol with easy
development and implementation. We can't ignore this issue - building a
protocol from nil - not using other legacy protocols - seems to me
neglecting the fact that we want the protocol to catch and be implemented.
B. As you know HTTP 1.1 support persistent connection - and therefore avoids
the connection start ups (on heavily used connections).
C. About the overhead. True, we could have done better in aspects of
optimizing the amount of data passed back and forth using TCP packets. But,
as I see it - another requirement is that the protocol should be
informative. In messaging context (as defined in SNAP) - from our experience
the overhead of HTTP is disputable.
D. About the request/response model - I think Lisa has a good point in the
extensibility of the protocol (mentioned later on) - where several sources
of notification are assumed - therefore - a request/response model seems to
me to be solving a set of problems - for example content-length - will
probably be different for different notification source types.

About ACKs.
Are "ACKs" required? - I think they are required indeed. In some cases, the
notification can be used as part of an application that is "mission
critical" for the end user. Having ACKs helps the notification source take
the appropriate action (for example retry) when the notification trigger is
not processed. Removing the ACKs leaves the notification source in some
doubt (especially in some end cases) which may cause losing (or duplicating)
notifications.

2. Profile information / subscription issues

In section 2.3 it says
	"..Email addresses can probably be used in some messaging scenarios,

	but what about other addresses? What if the server receiving the 
	notifications is not an email server but another kind of
notification
	aggregator?.."
I think the basic assumption (at least what we assume in SNAP) should be
that the notification server has the end user profile - in which -  it has a
mapping from one server identification to another. If the source is an email
server - there is no better (unique) identifier than the email address. The
notification server will need to know to map the address to some other
address domain, such as an SMS number.

About the subscription (section 2.4):
	".. Is it a requirement that the recipient of notifications be able
to
	choose which kinds are required?  This would allow the server to
	filter out notifications for accounts that are inactive, and
	notifications of uninteresting types.  It might greatly reduce the
	quantity of notifications used in the system. .. "
As we see the notification server  - it has two targets: event information
aggregator and a logic server that generates (according to user preferences)
notifications - e.g. send SMS on a new email. The notification server holds
the user profile and decides if an event is interesting or not. I agree that
we would like to reduce the amount of events in order to reduce the amount
of traffic - but this should be on a server to server integration basis and
not for each subscriber.

There is no question that the user should be able to choose which kinds of
notifications are required, and filter-out some notification types. But this
is on the level between the end-user and the notification aggregator -  not
necessarily between the notification aggregator and the notification source.
Sometimes, in order to implement a specific filtering scheme the
notification aggregator MUST HAVE ALL the notifications sent to it from the
notification source, in order to reliably implement a specific filtering
requested by the end-user.

I think in general that the issue of subscription should not be part of the
notification protocol. It isn't part of SMTP, IMAP and other protocols. I
think that we might need to consider (at least in the context of SNAP) a
protocol that will accompany the notification protocol and will define the
way provisioning should be done.

Another issue about profile information, Section 4.1 talks about language
negotiation. I think that the end user language should be part of the end
user profile - on the notification server. The notification server will need
to use different user agents in order to inform about the notification -
each one might have a different char-set and maybe different language.

3. Security issues

In section 3.3 it says:
	" ..It may be necessary for a notification aggregation server to
provide 
	authentication for the end  user in order to prove that access to
certain
	kinds of event information is allowed.."

I think there is a basic problem with this. It means that the notification
server will need to hold for each user on each notification source it's
password that needs to be coordinated each time it is changed in one side.
If the protocol will handle authorization and it will be encrypted (as the
draft does suggest) it will provide a good enough solution. Note that
assuming the notification server has the information on the subscriber
(profile) - once the notification source is authenticated and authorized -
for each user - the notification server can indicate if it is eligible for
service or not.

4. Extensibility (section 5)
This section comes back to the old dispute we had in the SNAP - do we want
XML or 2822 like format. I think that XML is more commonly used and it's
extensibility inherent. I would like to argue, though, that XML
processing/parsing is "heavier" than the 2822-like format option. I think
XML is an answer but not the only answer for extensibility and should not be
taken for granted.

Thanks,
Noam