Hi Avshalom,
http://www.ietf.org/internet-drafts/draft-houri-sipping-presence-scaling-requirements-01.txt
Typos in §4: with this problem?,
are considered? can be deleted.
http://www.ietf.org/internet-drafts/draft-houri-simple-interdomain-scaling-optimizations-00.txt
2.1 ... a single
NOTIFY per presentity in domain B -> should this not be domain
A?
2.1.1 "Complete
presence state information needs to be sent from the presentity's domain to
watcher's domain".
Is it not better
to filter this complete presence state information first by PS in domain A based
on a domain level privacy filter. Further specific watcher dependent filtering
is done in the PS of domain B.
As long as the
amount of different domains is limited, the trust and privacy filtering can be
handled and controlled in one or another way. However, when the PS has to
interwork with many different domains, how can the trust and privacy be kept
under control of the presentity? In the end, the presence state and the privacy
filtering is available on many, many different systems which can dynamically
change very often so that it's completely out of control. How can a presence
rule be updated in all these different domains? How long will it take and what
is the guarantee for it? Is the presentity still aware which watchers will
receive which presence state? Suppose the presentity wants to apply a new filter
to different watchers in different domains. How can it be guaranteed that this
is done in a synchronized way in all these different domains to avoid a mismatch
of the presence state?
2.1.2 NOTIFY
failure aggregation
Is the
subscription state of each watcher known by the presence server of the
presentity or is the subscription state only kept in the PS of the watcher?
What will be done
by the PS in domain A when the Notify failure indicates that a certain watcher
in domain B has not successfully received a NOTIFY message? Will a new NOTIFY
message be sent by the PS of domain B or will it be sent by PS of domain A
directly to the watcher or always to its PS?
2.1.3
Transferring the watcher list
When the watcher
list is part of the NOFITY message, could it then not make sense to do the
privacy filtering in domain A and determine which watchers belong to which
filtered documents and pass the different watcher lists and their related
presence document in function of the privacy filtering all together in one
message or in different messages in function of the filtered presence
document.
2.2 Batched
notification
...."The presence
server in domain B can then deliver the message to the watcher or create
individual NOTIFY messages for different watchers...." -> Should this not be
presentities (different NOTIFY messages to the watcher in function of the
presentity)?
2.3 Timed
presence
There are
indeed many different end-user requirements. Mostly, all people want to be
informed directly, until they have to pay in addition for that. In practice
however, there is something as "directly", "as soon as possible", "as late as
possible", "not after a certain moment in time", etc. Both the Presence
server of the presentity and the presence server of the watcher can make use of
these practices to optimize their traffic to serve the user as close as possible
with their wishes. When the capacity of the servers and the networks is
there, why not use this capacity to serve the end-user even
better?
2.4
On-Demand
This depends how
often the "poll" will be made. Misbehaving watchers can seriously affect the
performance of the PS.
Instead of a
SUBSCRIBE/NOTIFY, a RSS-feed mechanism as described in
draft-roy-simple-presencerss-01.txt could also be used as an on-demand
model.
3.
Conclusions
Same comment as
in other drafts: ".... if we do not think about scalability with the protocol
design it will not be very hard to scale."
-> not!
4. Security
considerations
Yes, this is a main concern. In principle, everybody is able to provide a presence server and provide this as a "free service" to many users. How can my presence server know which other worldwide available presence servers can be trusted?
_______________________________________________ Simple mailing list Simple at ietf.org https://www1.ietf.org/mailman/listinfo/simple