Re: [sixpac] Capability and preference expression and interrogation
Joe Hildebrand <joe.hildebrand@webex.com> Mon, 07 March 2011 13:54 UTC
Return-Path: <Joe.Hildebrand@webex.com>
X-Original-To: sixpac@core3.amsl.com
Delivered-To: sixpac@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABCE63A696B for <sixpac@core3.amsl.com>; Mon, 7 Mar 2011 05:54:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.21
X-Spam-Level:
X-Spam-Status: No, score=-105.21 tagged_above=-999 required=5 tests=[AWL=1.626, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6LyF2vh-fWw for <sixpac@core3.amsl.com>; Mon, 7 Mar 2011 05:54:56 -0800 (PST)
Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by core3.amsl.com (Postfix) with SMTP id D45FB3A67AC for <sixpac@ietf.org>; Mon, 7 Mar 2011 05:54:56 -0800 (PST)
Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Mar 2011 05:56:09 -0800
Received: from 66.114.169.8 ([66.114.169.8]) by SRV-EXSC03.webex.local ([192.168.252.200]) via Exchange Front-End Server mailus.webex.com ([66.114.175.12]) with Microsoft Exchange Server HTTP-DAV ; Mon, 7 Mar 2011 13:56:09 +0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Mon, 07 Mar 2011 06:56:07 -0700
From: Joe Hildebrand <joe.hildebrand@webex.com>
To: Gunnar Hellström <gunnar.hellstrom@omnitor.se>, sixpac@ietf.org
Message-ID: <C99A3207.4C4F3%joe.hildebrand@webex.com>
Thread-Topic: [sixpac] Capability and preference expression and interrogation
Thread-Index: Acvcz2fr1v2XwkBAB0Wy4l/NV56lAA==
In-Reply-To: <4D748C04.9090509@omnitor.se>
IM-ID: xmpp:jhildebr@cisco.com
Presence-ID: xmpp:jhildebr@cisco.com
Jabber-ID: jhildebr@cisco.com
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-OriginalArrivalTime: 07 Mar 2011 13:56:09.0623 (UTC) FILETIME=[697B7270:01CBDCCF]
Subject: Re: [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: Mon, 07 Mar 2011 13:54:58 -0000
In XMPP, this sort of thing is done with XEP-115 (http://xmpp.org/extensions/xep-0115.html). It's end-to-end, and is borne as a part of the presence of a device. 115 usually takes folks a while to get used to, so please set aside the time to do more than skim. On 3/7/11 12:40 AM, "Gunnar Hellström" <gunnar.hellstrom@omnitor.se> wrote: > The requirement to express the capability of XMPP messaging in SIP described > below also may need an extension for declaration of capability > details. REQ-y: Negotiable features in XMPP must be possible to express and > interrogate at SIP Session establishment level. Use case: Alice want to > send a nice HTML-formatted invitation letter to Bob. She wonders if she can > do it in a SIP session with messaging enabled. Therefore, when she calls Bob, > she indicates a desire to use Rich formatted messages. The resonse shows that > Bob has no capability for such features, so Alice decides to send an e-mail > instead and discuss it in a plain vice phone > call. Gunnar ------------------------------------- Gunnar Hellström skrev > 2011-02-08 20:16: > 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. > > Gunnar > > > ______________________________________________________________________________ > -- > > 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.t > xt >> >> 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 > > _______________________________________________ > sixpac mailing list > > sixpac@ietf.org > > https://www.ietf.org/mailman/listinfo/sixpac _________________________________ > ______________ sixpac mailing > list sixpac@ietf.org https://www.ietf.org/mailman/listinfo/sixpac -- Joe Hildebrand
- [sixpac] FW: New Version Notification for draft-v… Simo.Veikkolainen
- Re: [sixpac] FW: New Version Notification for dra… Elwell, John
- Re: [sixpac] FW: New Version Notification for dra… Simo.Veikkolainen
- Re: [sixpac] FW: New Version Notification for dra… Markus.Isomaki
- Re: [sixpac] FW: New Version Notification for dra… Markus.Isomaki
- [sixpac] Resolving SIP/XMPP URIs Markus.Isomaki
- Re: [sixpac] Resolving SIP/XMPP URIs Elwell, John
- Re: [sixpac] Resolving SIP/XMPP URIs Emil Ivov
- Re: [sixpac] Resolving SIP/XMPP URIs Simo.Veikkolainen
- Re: [sixpac] Resolving SIP/XMPP URIs Elwell, John
- [sixpac] Capability and preference expression and… Gunnar Hellström
- Re: [sixpac] FW: New Version Notification for dra… Elwell, John
- Re: [sixpac] Capability and preference expression… Gunnar Hellström
- Re: [sixpac] Capability and preference expression… Joe Hildebrand
- Re: [sixpac] Capability and preference expression… Simo.Veikkolainen
- Re: [sixpac] Capability and preference expression… Gunnar Hellström
- Re: [sixpac] Capability and preference expression… Simo.Veikkolainen
- Re: [sixpac] Capability and preference expression… Gunnar Hellström