Subject: [Speermint] requirements for presence and IM peering

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Oct 2009 10:03:59 -0600

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/

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 26 Oct 2009 11:36:28 -0600

Peter,

   Thank you for your review and for sending those comments to the list.
See my responses inline - let me know if the resolution looks ok to you.

Jean-Francois.

> -----Original Message-----
> From: [email-masked] [mailto:speermint-
> [email-masked]] On Behalf Of Peter Saint-Andre
> Sent: Tuesday, October 06, 2009 10:04 AM
> To: [email-masked]
> Subject: [Speermint] requirements for presence and IM peering
> 

> presence information via some explicit approval mechanism.

Agreed on both the requirement verb (changed MUST to SHOULD for the
reasons you invoke), and the text change.
New text for Requirement 10 now says:
	The mechanisms recommended for the exchange of presence
information between SSPs SHOULD allow a user of one presence community
to send a presence subscription request to 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.

> communication (IM and groupchat) but not sending files, etc.

Ok, changed the requirement #11 to be:
	The mechanisms recommended for Instant Messaging exchanges
between SSPs SHOULD allow a user of one SSP's community to communicate
with users of the other SSP community via their local community using
the various methods.  Note that some SSPs may exercise some control over
which methods are allowed based on service policies.

> meant, or to point to the security considerations.

Thank you for the comment; this requirement needed a good rewrite.
The new text says:
o  Requirement #12: Privacy Sharing
   In some presence communities, users can define the list of
   watchers that receive presence notifications for a given
   presentity.  Such privacy settings for watcher notifications per
   presentity are typically not shared across SSPs causing multiple
   notifications to be sent for one presentity change between SSPs.
   The sharing of those privacy settings per presentity between SSPs
   would allow fewer notifications: a single notification would be
   sent per presentity and the terminating SSP would send
   notifications to the appropriate watchers according to the
   presentity's privacy information.
   The mechanisms recommended for Presence information exchanges
   between SSPs SHOULD allow the sharing of some user privacy
   settings in order for users to convey the list of watchers that
   can receive notification of presence information changes on a per
   presentity basis.
   The privacy sharing mechanism must be done with the express
   consent of the user whose privacy settings will be shared with to
   the other community.  Because of the privacy-sensitive information
   exchanged between SSPs, the protocols used for this exchange must
   follow the security recommendations defined in section 6 of
   [RFC3863].

> therefore worthy of protection, just as under Requirement #12.

ok, the note now in req #12 should address this:
Because of the privacy-sensitive information exchanged between SSPs, the
protocols used for the exchange of presence information must follow the
security recommendations defined in section 6 of <xref
target="RFC3863"/>.

>       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.
> 
> tables, because the maintenance issues are significant and there is
> no need to do this given that we have PIDF.
Agreed, dropped the alternative to exchange translation tables.
The new text now says:

   o  Requirement #14: Standard PIDF Documents and Mappings
      Early deployments of SIP-based presence and Instant Messaging
      gateways have been done in front of legacy proprietary systems
      that use different naming schemes or name values for the elements
      and properties defined in a Presence Information Data Format
      (PIDF) document ([RFC3863]).  For example the status value "Do Not
      Disturb" in one presence service may be mapped to "Busy" in
      another system.  Beyond this example of
      status values, the meaning of the presence information should be
preserved between SSPs.
      The systems used to exchange presence documents between peers
      SHOULD use standard PIDF documents and translate any non-standard
      value of a PIDF element to a standard one.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Oct 2009 14:52:50 -0600

> See my responses inline - let me know if the resolution looks ok to you.

Thank you, Jean-Francois. All of your resolutions address my concerns.

Peter