[sixpac] Capability and preference expression and interrogation

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Tue, 08 February 2011 19:16 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: sixpac@core3.amsl.com
Delivered-To: sixpac@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 9DBAF3A672E for <sixpac@core3.amsl.com>; Tue, 8 Feb 2011 11:16:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id dyPRaE7CUwp1 for <sixpac@core3.amsl.com>; Tue, 8 Feb 2011 11:16:43 -0800 (PST)
Received: from vsp-outgoing1.binero.net (vsp-outgoing1.binero.net []) by core3.amsl.com (Postfix) with SMTP id 235603A682C for <sixpac@ietf.org>; Tue, 8 Feb 2011 11:16:21 -0800 (PST)
Received: from smtp01.binero.se (unknown []) by vsp-outgoing1.binero.net (Halon Mail Gateway) with ESMTP for <sixpac@ietf.org>; Tue, 8 Feb 2011 20:16:18 +0100 (CET)
Received: from [] (h225n1fls32o933.telia.com []) by smtp-03-01.atm.binero.net (Postfix) with ESMTPA id 059CF3A17A for <sixpac@ietf.org>; Tue, 8 Feb 2011 20:16:18 +0100 (CET)
Message-ID: <4D519681.4070404@omnitor.se>
Date: Tue, 08 Feb 2011 20:16:17 +0100
From: =?UTF-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= <gunnar.hellstrom@omnitor.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv: Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: sixpac <sixpac@ietf.org>
References: <F9E2FDAF48D4544F874A56A3A8BD68B13BC79A@008-AM1MPN1-003.mgdnok.nokia.com>
In-Reply-To: <F9E2FDAF48D4544F874A56A3A8BD68B13BC79A@008-AM1MPN1-003.mgdnok.nokia.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: [sixpac] Capability and preference expression and interrogation
X-BeenThere: sixpac@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." <sixpac.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sixpac>, <mailto:sixpac-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sixpac>
List-Post: <mailto:sixpac@ietf.org>
List-Help: <mailto:sixpac-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sixpac>, <mailto:sixpac-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Feb 2011 19:16:44 -0000

I think it is important that the capability to do XMPP messaging with a 
SIP endpoint is expressed in regular SIP ways, so that capability 
checking for that function even can be done before a session is 
initiated, and also during session initiation. E.g. the functionality 
should have the possibility to influence the outcome of caller 
preferences - callee capabilities interrogations (RFC 3840, RFC 3841 ).

It seems to me that that is easily achieved, but that is not the issue 
at the moment, when collecting requirements.
I cannot find exactly that need described in the current requirements, 
so I suggest to add a requirement like this:

REQ-x: The capability or preference to initiate and accept XMPP messages 
must be possible to express and interrogate by the standard mechanisms 
for such functions in SIP for caller preferences and callee 
capabilities. ( RFC 3840, RFC 3841 etc.)

Use case: Alice want to call Bob to have his view of some new poems she 
has written. She has a SIP phone with XMPP chat addition. She makes sure 
that her phone expresses a preference for audio and text messaging in 
the call. Bob has two phones registered on his address. One only with 
audio functionality, the other with both audio and text messaging. The 
SIP server can match the Alice's preferences with the capabilities of 
Bob's phones, and direct the call to the device where he can receive and 
read the poems and comment them in their voice conversation.


I am not sure if similar standardised features are available for XMPP so 
that it is relevant to express the symmetric requirements on the XMPP side.


Simo.Veikkolainen@nokia.com skrev 2011-01-26 21:20:
> You're right, we should get some discussion going on.
> I have just uploaded a new version of draft-veikkolainen-sip-xmpp-coex-reqs, which can be found at http://www.ietf.org/internet-drafts/draft-veikkolainen-sip-xmpp-coex-reqs-02.txt
> The changes in this version address the comments made by Peter Musgrave (mainly clarifications):
> In REQ-1: “SIP contact” changed to “SIP address”
> In REQ-3: "It must be possible to include SIP real-time media related contact and status in XMPP presence information." changed to "It must be possible to include SIP address and status information in XMPP presence."
> And a couple of typos.
> One further comment made by Peter might merit a bit more discussion, namely saying something about cases where two SIP devices are registered to the same AOR and two XMPP clients are logged in. This is related to the discussion we had an correlation, and whether or not it should be mentioned in the charter or not.
> Opinions on this would be helpful.
> Also, please take a fresh look at the draft and express your opinions on whether the approach in general makes sense, do you agree with the use cases and requirements, is something missing etc.
> Thanks
> Simo
> -----Original Message-----
> From: ext IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
> Sent: 26 January, 2011 22:05
> To: Veikkolainen Simo (Nokia-MS/Helsinki)
> Cc: Isomaki Markus (Nokia-CIC/Espoo)
> Subject: New Version Notification for draft-veikkolainen-sip-xmpp-coex-reqs-02
> A new version of I-D, draft-veikkolainen-sip-xmpp-coex-reqs-02.txt has been successfully submitted by Simo Veikkolainen and posted to the IETF repository.
> Filename:	 draft-veikkolainen-sip-xmpp-coex-reqs
> Revision:	 02
> Title:		 Requirements and Use Cases for Combining SIP Based Real-time Media Sessions With XMPP Based Instant Messaging and Presence Service.
> Creation_date:	 2011-01-26
> WG ID:		 Independent Submission
> Number_of_pages: 8
> Abstract:
> This memo defines use cases and requirements for combining Session
> Initiation Protocol (SIP) based real-time media sessions with
> Extensible Messaging and Presence Protocol (XMPP) based instant
> messaging and presence services in a seamless manner.
> The IETF Secretariat.
> _______________________________________________
> sixpac mailing list
> sixpac@ietf.org
> https://www.ietf.org/mailman/listinfo/sixpac