Subject: [xmpp] draft-saintandre-sip-xmpp-presence-02

From: Michael Lundberg <[email-masked]>
Date: Wed, 26 Jan 2011 09:21:57 -0500

Hi All,

I am interested in renewing discussion on
http://tools.ietf.org/html/draft-saintandre-sip-xmpp-presence-02 and
the corresponding SIP-XMPP interworking I-Ds.

After reading through the documentation, it's my understanding there
are two ways presence information can be mapped between these two
protocols.

1. For each RFC that extends PIDF to support additional presence
values/information, a corresponding RFC to extend XMPP is required
(and vise versa).  Then develop a RFC that describes the mapping
between the two protocols for the presence info.

2. Encapsulate PIDF, and any corresponding extensions to PIDF, in XMPP

Option 1 requires a lot more standards development, since for each
extension, 3 RFCs need to be developed.  However, this option provides
the best way to convey the same presence information across both
protocols.

Option 2 only requires a single SIP-XMPP presence "mapping" RFC. Any
extension to PIDF will automatically be encapsulated in XMPP presence
stanzas.  However, this is only a one-way mapping.  Rich presence
information conveyed in XMPP cannot be translated to SIP, without the
development of a separate RFC.  This option also requires the XMPP end
host to be able to understand the PIDF file.  Although protocol
mapping (i.e., PIDF encapsulation) occurs at the gateway (located at a
client, xmpp server, or separate gateway device), the XMPP end host
must be able to understand the encapsulated PIDF information if it is
being used to carry the presence info.

The current SIP-XMPP Interworking: Presence I-D does not seem to take
a firm stance on either of the above options.

For Option 1, there is no mapping between the XMPP <show> values and a
child within the PIDF <status>.  In RFC3922, the
urn:ietf:params:xml:ns:pidf:im namesapace was used to map this
information.  Although, that namespace does not seem appropriate,
because the presence info could be from any type of service/device,
not just IM; however, a similar mapping seems like it could be
defined.  I’m also not sure why the current mapping is a SHOULD and
not a MUST in the document.

For Option 2, the encapsulation of the PIDF information is described
as a RECOMMENDATION.  It seems as though if the purpose of the draft
is to promote interoperability between the two protocols, then
stricter wording is required to support one of the two Options, as
this will impact future draft development.

Please let me know if I am missing something, as I was not involved in
the original discussions surrounding the development of this I-D. I
think this is good work that needs to continue in order to promote
interworking between these two protocols.

Thanks,
Michael