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

[Peter Saint-Andre <[e-mail]>]

On 7/26/13 5:55 PM, Peter Saint-Andre wrote:
> On 7/26/13 4:50 PM, Michael Lundberg wrote:
> 
>> 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?
>>
>>> 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.
> 
> 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.

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/