Subject: [Stox] Comments on draft-ietf-stox-presence-00

From: Michael Lundberg <[email-masked]>
Date: Fri, 19 Jul 2013 08:01:06 -0400

Peter,
I think draft-ietf-stox-presence-00 looks good.  I had a previous comment
to an earlier version that was not addressed that I'm incuding it again as
I think it is important for the document.

I think it would be good to add the <show/> element to Table 7, with a note
similar to the one provided in Table 6.  This will provide a method for
mapping 'away' and 'dnd' information in the opposite direction.  Similar to
the note in Table 6, this would require the SIP implementation to support
the 'jabber:client' namespace.  If the SIP implementation supports the
namespace, the gateway can then map the values directly into the <show/>
element of the XMPP presence messages.

The only other thing I saw was that the below sentence in Section 3.2.3 is
missing the word "send" after SHOULD.

Current:

Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway SHOULD a
presence stanza of type "unsubscribed" to the XMPP user:

New:

Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway SHOULD
send a presence stanza of type "unsubscribed" to the XMPP user:

Regards,
Michael

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Jul 2013 21:08:33 -0600

Hi Mike, thanks for the feedback.

On 7/19/13 6:01 AM, Michael Lundberg wrote:
> Peter,
> 
> I think draft-ietf-stox-presence-00 looks good.  I had a previous 
> comment to an earlier version that was not addressed that I'm
> incuding it again as I think it is important for the document.

Sorry I missed that.

> I think it would be good to add the <show/> element to Table 7,
> with a note similar to the one provided in Table 6. This will
> provide a method for mapping 'away' and 'dnd' information in the
> opposite direction.

Agreed.

(BTW, these are actually Table 1 and Table 2 -- we need to fix the
numbering.)

> Similar to the note in Table 6, this would require the SIP 
> implementation to support the 'jabber:client' namespace.  If the
> SIP implementation supports the namespace, the gateway can then map
> the values directly into the <show/> element of the XMPP presence
> messages.

True.

One clarifying question: when you say "if the SIP implementation
supports the namespace", do you mean the XMPP-to-SIP gateway or the
SIP user agent?

> The only other thing I saw was that the below sentence in Section
> 3.2.3 is missing the word "send" after SHOULD.
> 
> Current:
> 
> Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway
> SHOULD a presence stanza of type "unsubscribed" to the XMPP user:
> 
> New:
> 
> Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway
> SHOULD send a presence stanza of type "unsubscribed" to the XMPP
> user:

Noted. :-)

Peter

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

---

From: Michael Lundberg <[email-masked]>
Date: Fri, 26 Jul 2013 10:50:35 -0400

Peter,

Thanks.  See below for a response to your question.

Thanks,
Michael

On Tue, Jul 23, 2013 at 11:08 PM, Peter Saint-Andre <[email-masked]> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Good question.  It would be benificial if both supported the
namespace, but only the gateway is probably required to.  If the
client supports the namespace, then the gateway would just need to map
between the elements described in this document.

If the client doesn't support the namespace, the gateway would most
likely need to do an additional translation into a namespace the
client does understand.  In this case, the values might not be the
same between the two namespaces, and therefore things are 'lost' in
translation. This is one of the big issues with presence mapping today
as many implementations have thier own implementation specific
namespace, which makes it hard to map between different
implementations.  Both the implementation specific and common
namespaces could coexist, where the implementation specific namespace
is used for internal communication and a common, standard namespace
(e.g., 'jabber:client' ) is used when communicating between different
implementations.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJR70UxAAoJEOoGpJErxa2pGHgP/3egwP1prfQ0se36jXI6wlR4
> LaYerbpXqnTBrlHXft1sVvCCVFHpCbRgRecUYm5sFwC5nDtxN83u4UpVEuijO7Wv
> ajMYLNNz3m0z/Vo2nfK94FzH5wK2tVNWBV5orAbIfc+SH60WTw2HOgSntoK/yvTK
> iiX8hpfYTv09ZX3iE4ZnBoPVEqG2oxo9CKouCRl4WxwPEE3rZF+PcOn6PvmPWpvE
> Xf5htIDKmvOv53mM4OU7KpR0j+2QyS6egkbOOsxki0gT/m5ZYm1HmF2WA4b5LXOl
> 1/mM+KQM2qukcr5BHVy2HV53cybkCx8Nf5DhtkXOG5Ti57jiWgvomeLDOTqgLf3w
> 8yFgLKHD4RFb6z/9k8k4EdHx9aMO+HhCMkKK2qeHPc6cf96vjMKAASMdjcRsmlOu
> 0pzudOpe9cfRnzSQamn6/0/H7JX/9O8fZ2Ya7/Cb6qdr7KUCrOAIRIgK07fmMDIY
> G3lgXSkzQTrYuIQ34mp+jXEdZf3+J4B422y8UvoZ5QmgVMNNrkARuv+DWnGprCrQ
> EnKnbFGJbdNfLuof5RTg8FaJofKeWPCj2UAsRbVn0le1sbjoy43hvRF9r5Gv5KzG
> 2K9Ei8/XoYPkZRWdst6/RpQ/R5Nox40xK/SCWs067P7qsTKGByciEJVAjm336vAy
> vFM/cMMZUGP6KyKTxwaJ
> =YNJV
> -----END PGP SIGNATURE-----

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 26 Jul 2013 17:55:37 +0200

>> (e.g., 'jabber:client' ) is used when communicating between different

Yes, I think that makes sense. I'm not sure exactly how to translate
that into text (especially the part about proprietary / non-standard
namespaces), but I'll work something up for consideration by the list.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 29 Jul 2013 12:49:34 +0200

> namespaces), but I'll work something up for consideration by the list.

Here is some proposed text:

OLD
   5.  Some implementations support custom extensions to encapsulate
       this information; however, there is no need to standardize a PIDF
       extension for this purpose, since PIDF is already extensible and
       thus the <show/> element can be included directly, qualified by
       the 'jabber:client' namespace in the PIDF XML.  The examples in
       this document illustrate this usage, which is RECOMMENDED.  The
       most useful values are likely "away" and "dnd", although note
       that the latter value merely means "busy" and does not imply that
       a server or client ought to block incoming traffic while the user
       is in that state.

NEW
   5.  Some implementations support custom extensions to encapsulate
       detailed information about availability; however, there is no
       need to standardize a PIDF extension for this purpose, since
       PIDF is already extensible and thus the <show/> element
       (qualified by the 'jabber:client' namespace) can be included
       directly in the PIDF XML.  The examples in this document
       illustrate this usage, which is RECOMMENDED.  The most useful
       values are likely "away" and "dnd", although note that the
       latter value merely means "busy" and does not imply that a
       server or client ought to block incoming traffic while the user
       is in that state.  Naturally, a gateway can choose to translate
       a custom extension into an established value of the <show/>
       element [RFC6121], or translate a <show/> element into a custom
       extension that the gateway knows is supported by the user agent
       of the intended recipient.  Unfortunately, this behavior does
       not guarantee that information will not be lost; to help prevent
       information loss, a gateway ought to include both the <show/>
       element and the custom extension if the gateway cannot suitably
       translate the custom value into a <show/> value.

Mike, does that text address your concern? Do we need to say more (or
less) than that?

Peter

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

---

From: Michael Lundberg <[email-masked]>
Date: Wed, 31 Jul 2013 21:17:57 -0400

Peter,

The suggest text below makes sense to me.  In my opinion, this helps
more clearly defining the presence mapping from XMPP to SIP for values
such as 'away'.

I think there needs to be similar text for the second table (currently
labeled Table 6), which states that the gateway SHOULD map the <show
xmlns='jabber:client'> element in the PIDF XML to the <show/> element
in the XMPP presence stanza.  This would only be for SIP clients that
support that particular namespace, but it at least provides a
recommended mapping in the opposite direction for clients that do
support that namespace.

~Michael