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

From: Tory Patnoe <[email-masked]>
Date: Mon, 07 Feb 2011 11:30:57 -0700

I¹d also like to see an Option 3.

3. Clarify the subscription model between XMPP and SIP.

This is addressed in section 2.3.2 but I believe needs some clarification.

2.3.2 talks about the subscription-state: terminated; reason=timeout but
doesn¹t deal with other SIP reasons and how they should be turned into XMPP
presence.

-- Tory

On 2011-1-26 7:21 AM, "Michael Lundberg" <[email-masked]>
wrote:

> 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
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: "Peter Saint Andre" <[email-masked]>
Date: Mon, 7 Feb 2011 11:32:39 -0800

Suggestions are welcome. I'm very open to updating this document series. Feedback and reviews will help us make faster progress. 

________________________________

From: [email-masked] <[email-masked]> 
To: Michael Lundberg <[email-masked]>; XMPP <[email-masked]> 
Sent: Mon Feb 07 10:30:57 2011
Subject: Re: [xmpp] draft-saintandre-sip-xmpp-presence-02 

I’d also like to see an Option 3.

2.3.2 talks about the subscription-state: terminated; reason=timeout but doesn’t deal with other SIP reasons and how they should be turned into XMPP presence.

-- Tory

On 2011-1-26 7:21 AM, "Michael Lundberg" <[email-masked]> wrote:

	Hi All,

	

	

	defined.  I’m also not sure why the current mapping is a SHOULD and

	
	Thanks,
	Michael