[Speermint] requirements for presence and IM peering

[Peter Saint-Andre <stpeter at stpeter.im>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Section 4 of draft-ietf-speermint-requirements contains requirements for
peering of presence and instant messaging in SIP-based systems. Here is
some feedback regarding those requirements.

In general, I am concerned about the use of the capitalized keyword MUST
in these requirements, because it could be taken to override local
policies or user-level privacy settings. For example, if we say that an
entity absolutely MUST be allowed to subscribe to the presence of users
in another SSP then operators might take that as saying that a user or a
service-wide admin cannot block an entity from another SSP (or all
entities from another SSP) from subscribing to the user's presence. I
don't think this is what we mean here, but we need to make that clear.

Some specific comments follow.

Requirement #10

      The mechanisms recommended for the exchange of presence
      information between SSPs MUST allow a user of one SSP's presence
      community to subscribe presentities served by another SSP via its
      local community, including subscriptions to a single presentity, a
      personal, public or ad-hoc group list of presentities.

The phrase "to subscribe presentities" is missing some words. I think
"to subscribe to presentities" is meant. However, I think it is better
to say "to send a presence subscription request to presentities" because
presumably the presentity needs to control who can and cannot see its
presence information via some explicit approval mechanism.

Requirement #11

      The mechanisms recommended for Instant Messaging message exchanges
      between SSPs MUST allow a user of one SSP's community to
      communicate with users of the other SSP community via their local
      community using various methods.  Such methods include sending a
      one-time IM message, initiating a SIP session for transporting
      sessions of messages, participating in n-way chats using chat
      rooms with users from the peer SSPs, sending a file or sharing a
      document.

Use cases such as sending a file and sharing a document are not IM use
cases. Furthermore, the text seems to imply that an SSP cannot exercise
any granular control over which of the "various methods" are allowed. In
my experience, an SSP might allow IMs but not groupchats, textual
communication (IM and groupchat) but not sending files, etc.

Requirement #12

      In order to enable sending less notifications between communities,
      there should be a mechanism that will enable sharing privacy
      information of users between the communities.  This will enable
      sending a single notification per presentity that will be sent to
      the appropriate watchers on the other community according to the
      presentity's privacy information.
      The privacy sharing mechanism must be done in a way that will
      enable getting the consent of the user whose privacy will be sent
      to the other community prior to sending the privacy information.
      if user consent is not give, it should not be possible to this
      optimization.  In addition to getting the consent of users
      regarding privacy sharing, the privacy data must be sent only via
      secure channels between communities.

Usage: "less ... notifications" ==> "fewer ... notifications".

Typos: "if user consent is not give, it should not be possible to this
optimization." ==> "If user consent is not given, it should not be
possible to use this optimization."

The phrase "secure channels" is not defined. Does this mean SIP
signalling over TLS-encrypted TCP? It would be good to specify what's
meant, or to point to the security considerations.

Requirement #13

      It should be possible to send a presence document with a list of
      watchers on the other community that should receive the presence
      document notification.  This will enable sending less presence
      document notifications between the communities while avoiding the
      need to share privacy information of presentities from one
      community to the other.

Usage: "less ... notifications" ==> "fewer ... notifications".

This requirement says nothing about security. Presumably, information
about the recipients of a given notification might also be private and
therefore worthy of protection, just as under Requirement #12.

Requirement #14

      Early deployments of SIP based presence and IM gateways are done
      in front of legacy proprietary systems that use different names
      for different properties that exist in PIDF.  For example "Do Not
      Disturb" may be translated to "Busy" in another system.  In order
      to make sure that the meaning of the status is preserved, there is
      a need that either each system will translate its internal
      statuses to standard PIDF based statuses of a translation table of
      proprietary statuses to standard based PIDF statuses will be
      provided from one system to the other.

Usage: In "different names for different properties" I would change the
second instance of "different" to "various".

The final sentence is a bit confusing and its directive to SSPs is not
clear, even if we correct "of" to "or" in the middle. I might reword it
as follows:

      To make sure that the meaning of the status is preserved, an SSP
      should translate its internal statuses to standard PIDF statuses.

I don't think we want to recommend that SSPs exchange translation
tables, because the maintenance issues are significant and there is no
need to do this given that we have PIDF.

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrLam8ACgkQNL8k5A2w/vz+mwCg3k58ehq3IOmho/y3Jnplcrrj
IHkAn2s2RMJ63746RtLjfd3/LF6qq9el
=ksSN
-----END PGP SIGNATURE-----