Re: [Speermint] requirements for presence and IM peering

["Jean-Francois Mule" <jf.mule at cablelabs.com>]

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: speermint-bounces at ietf.org [mailto:speermint-
> bounces at ietf.org] On Behalf Of Peter Saint-Andre
> Sent: Tuesday, October 06, 2009 10:04 AM
> To: speermint at ietf.org
> Subject: [Speermint] requirements for presence and IM peering
> 


> 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.


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.


> 
> 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.

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.

> 
> 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.



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].


> 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.

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"/>.

> 
> 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.
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.


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