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

[Michael Lundberg <[e-mail]>]

On Mon, Mar 11, 2013 at 9:51 AM, Peter Saint-Andre <[e-mail]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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.
>>
>> 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.
>
> 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.
>
>> 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).
>
> One option, as I suggested in the I-D, is to use the 'jabber:client'
> namespace, for instance:
>
> <show xmlns='jabber:client'>away</show>

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.

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

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.

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