Subject: [dispatch] Comments on draft-saintandre-sip-xmpp-presence-04

From: Michael Lundberg <[email-masked]>
Date: Sat, 9 Mar 2013 19:29:01 -0500

Peter,

Thanks for resubmitting the SIP-XMPP presence I-D.  I think this and
the other documents are important as there are a lot of interworking
issues today with XMPP and SIP/SIMPLE implementations, and I think
these documents can help reduce some of those interworking challenges.

In order to help ensure interworking between different
implementations, I think Sections 5.2 and 5.3 need to have some
stronger ‘MUST’ language instead of SHOULDs, MAYs, etc.  This will
enforce proper and complete mappings between implementations that
conform to this document.

While I don’t think the document needs to enforce the use of the
<show/> element mapping discussed in 5.2, I think if implementations
are going to use the mapping, this document should enforce the use of
a specific namespace and describe the mapping of <show> values
specified in RFC 6121 (i.e., away, dnd, chat, and xa).  This will at
least allow a minimum set of standard mappings between XMPP and SIP,
which can be expanded on in future document(s).  Section 5.3 could
then also discuss how this mapping can be accomplished from SIP to
XMPP if the SIP endpoints/devices support this same namespace.  One of
the big interworking challenges with today’s implementations is the
use of different namespaces given the extensibility of XML-based
presence standards (e.g., PIDF, RPID), which allows individuals to
create their own namespace.  This flexibility is good for ingenuity,
but problematic for interworking between different implementations.  I
think standardizing a basic set of common status information using a
specific namespace is needed, and this document is a good place to do
that.

In my opinion, I do not think Section 6 should be part of this base
document.  While I like the idea of encapsulating the SIP <presence>
information into the XMPP message, I think this content should be a
consideration for implementing ‘rich presence’.  As written, this
method is only applicable for SIP to XMPP translation, and if the
focus of this document is just ‘basic’ presence information
interworking, the SIP to XMPP mapping in Section 5.3 already describes
a method for how this can be accomplished.

Regards,
Michael

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 11 Mar 2013 09:51:48 -0400

On 3/9/13 7:29 PM, Michael Lundberg wrote:
> Peter,
> 
> Thanks for resubmitting the SIP-XMPP presence I-D.  I think this
> and the other documents are important as there are a lot of
> interworking issues today with XMPP and SIP/SIMPLE implementations,
> and I think these documents can help reduce some of those
> interworking challenges.
> 

Quite possibly. In general I think it might be good to have a
discussion about how strong we want to make the recommendations in
this suite of documents.

> <show/> element mapping discussed in 5.2, I think if
> implementations are going to use the mapping, this document should
> enforce the use of a specific namespace and describe the mapping of
> <show> values specified in RFC 6121 (i.e., away, dnd, chat, and
> xa).

One option, as I suggested in the I-D, is to use the 'jabber:client'
namespace, for instance:

<show xmlns='jabber:client'>away</show>

However, I have heard that different presence/IM systems have
different interpretations of the "dnd" (do not disturb) state. So I
think we might need to work that out.

> This will at least allow a minimum set of standard mappings between
> XMPP and SIP, which can be expanded on in future document(s).
> Section 5.3 could then also discuss how this mapping can be
> accomplished from SIP to XMPP if the SIP endpoints/devices support
> this same namespace.  One of the big interworking challenges with
> today’s implementations is the use of different namespaces given
> the extensibility of XML-based presence standards (e.g., PIDF,
> RPID), which allows individuals to create their own namespace.
> This flexibility is good for ingenuity, but problematic for
> interworking between different implementations.  I think
> standardizing a basic set of common status information using a 
> specific namespace is needed, and this document is a good place to
> do that.

That seems helpful.

> In my opinion, I do not think Section 6 should be part of this
> base document.  While I like the idea of encapsulating the SIP
> <presence> information into the XMPP message, I think this content
> should be a consideration for implementing ‘rich presence’.  As
> written, this method is only applicable for SIP to XMPP
> translation, and if the focus of this document is just ‘basic’
> presence information interworking, the SIP to XMPP mapping in
> Section 5.3 already describes a method for how this can be
> accomplished.

IMHO it would be fine to remove Section 6, unless someone really wants
it to be in this spec.

Thanks for the feedback!

Peter

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

---

From: Michael Lundberg <[email-masked]>
Date: Mon, 11 Mar 2013 16:53:46 -0400

On Mon, Mar 11, 2013 at 9:51 AM, Peter Saint-Andre <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

I'm ok with using this namespace.  I just want to make sure this isn't
left up to whatever namespace the implementer wants to use. Right now
the document says we don't need to standardize on this particular
issue, and that xmlns='jabber:client' is used in the example.  I just
want to take it a step further and say that xmlns='jabber:client'
should be used for the following presence value mappings x, y, z
between XMPP and SIP.

> think we might need to work that out.

I think this is a good point and a good discussion topic.  One way to
potentially address this is to map 'dnd' from one protocol to some
other value or state in another protocol.  Alternatively, you could do
the one-to-one mapping and leave it up to implementations to address
the interpretations of dnd in either a passive or proactive manner.
The gateway could send in the 'free text' portion of the presence
message whether or not the user can receive messages when he/she is in
a 'dnd' state.  The gateway could also respond to individuals who try
and message a user who is in a 'dnd' state that the "individual can't
receive messages".

In my opinion, I think this behavior should be left up to
implementation.  This document may want to suggest some ways that it
could be handled.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJRPeFzAAoJEOoGpJErxa2pm6sP/3C+XEW4gUcnwHuCT0sHfTYi
> YOSzqzK+HT0fHjXRYjRthGu3ZF7qfBv4ak+0oR9GuzxzL49aku9HUcTCN8ZX9132
> i85Fh/UxFGi1kHTu0g+YF1cIHas4niy4EYtZ7IyHoQ1aV1t9M+yvXH+8laEkAJ7V
> oBiCFtLMPDd64pXc8pxA8RS5NWgYEoYX89xEOXIh7vApVozT4DcsOmm/DBH7wmxG
> 0T/3dBCo6OYtJz0oBYhP8SwyxEQfpz1+2QSUulEfbhUN7ZuBZGNdWLLkxOeQq1gZ
> aSLNb6BZkxp2mGrFu2TblTW+E8wz7GVzua41+JvyU9ipXTfkEoDJVTAZTx1tdPDX
> HruAIB4p7e3MRFLBzDzYzUqH0OXfjt7EYV93fr9k7GKpGn6/mjlkr6i23b5dz/19
> kZCt4Z9xSOLTxy9t3h2evd6huZrXeqkbCyXW7fB2wGam3/366/TDiYb3MTWxougV
> CveADTd3O9BKGobTu1laKaep6+ZqsWIUoYaxw2TFL1edUUqGDNlaw1b3+H1mjwHz
> dEFYAjDPMk3qiS7u7nrdTOE3fP4HkMoJoSZjZ+2z3YDpc44X5m1h0YqU4uxOiNsq
> Kjai2O3311z5qrZqICkn2l+mJh31JXPt35Jb+F8V2ztAImSf50HMQJFIC1FkMFNG
> vKUYWw6m+bj++I8ue21l
> =t1Zx
> -----END PGP SIGNATURE-----