From paymentoffice65@gmail.com Sun Aug 3 11:55:20 2008 Return-Path: X-Original-To: ietfarch-simple-archive@core3.amsl.com Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A02C3A6C0B; Sun, 3 Aug 2008 11:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.977 X-Spam-Level: **** X-Spam-Status: No, score=4.977 tagged_above=-999 required=5 tests=[BAYES_50=0.001, KAM_LOTTO1=2.899, SUBJ_ALL_CAPS=2.077] 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 2Ga8WjfZnBa2; Sun, 3 Aug 2008 11:55:20 -0700 (PDT) Received: from cumdfirewall.uniminuto.edu (mail.uniminuto.edu.co [190.24.131.35]) by core3.amsl.com (Postfix) with ESMTP id A79C33A691C; Sun, 3 Aug 2008 11:55:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by cumdfirewall.uniminuto.edu (Postfix) with ESMTP id 3E8842B52F; Sun, 3 Aug 2008 13:38:14 -0500 (COT) X-Virus-Scanned: amavisd-new at uniminuto.edu Received: from cumdfirewall.uniminuto.edu ([127.0.0.1]) by localhost (cumdfirewall.uniminuto.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6bkSBA1Vei8; Sun, 3 Aug 2008 13:38:08 -0500 (COT) Received: from correo.uniminuto.edu (localhost [127.0.0.1]) by cumdfirewall.uniminuto.edu (Postfix) with ESMTP id 3C5A42F1AD; Sun, 3 Aug 2008 13:31:11 -0500 (COT) Received: from 75-2.vgccl.net ([41.220.75.2]) (SquirrelMail authenticated user fmuriel) by correo.uniminuto.edu with HTTP; Sun, 3 Aug 2008 13:31:12 -0500 (COT) Message-ID: <4819beac5ba47eb78761dfe3fe9106bc.squirrel@correo.uniminuto.edu> Date: Sun, 3 Aug 2008 13:31:12 -0500 (COT) Subject: YOU ARE A WINNER!!! From: "COCA COLA LOTTERY BOARD" Reply-To: paymentoffice64@gmail.com User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; ----- REG ORDER NO:ECL/68276/08 22 Garden Close, SE9 2YP,London United Kingdom THE COCACOLA COMPANY OFFICIAL PRIZE NOTIFICATION ATTENTION WINNER: We are pleased to inform you of the result of the just concluded draws held today by Coca-Cola .Your E-mail was among the 20 Lucky winners who won £500,000.00{Five Hundred Thousand Great Britain Pounds} each in the Coca-Cola Company 2008 online Promo. This draw is being organized to enhance awareness and publicity of the Coca-Cola Zero product. Your E-mail was attached to Ticket number (8VKVIZ2008) and Ballot number (BT:31282008/20) The online draws was conducted by a random selection of E-mail addresses from an exclusive list of 29,031,643 E-mail addresses of individuals and corporate bodies picked by an advanced automated random computer search from the internet. No Tickets were sold but all e-mail addresses were assigned to different Ticket numbers for representation and privacy. To begin the claim processing of your prize you are to contact your claims Agent and provide him with the following informations as stated below, so we can proceed with the verification and clearance process of your file: 1. Full Names : ......................................................... 2. Residential Address : ....................................................... 3. Phone Number(Mobile&Home): ...................................................... 4. Fax Number : ......................................................... 5. Occupation : ......................................................... 6. Sex : ......................................................... 7. Age : ......................................................... 8. Nationality : .......................................................... 9.Ballot No. : .......................................................... 10.Ticket No: ........................................................... 11.Preferred Choice of receiving Winnings: (A):Via Courier Delivery Of Certified Cheque. (B):Bank wire Transfer. Mr Allan Edwards. claims Agent, Email: paymentoffice64@googlemail.com Tel:+447 045 798 693 FAX:+447 005 938 689 Yours Faithfully, Cruze Benze(Esq). Management From simple-bounces@ietf.org Mon Aug 4 18:33:58 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F31F3A6832; Mon, 4 Aug 2008 18:33:58 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF333A687E for ; Mon, 4 Aug 2008 18:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] 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 smUz+g8y9SFg for ; Mon, 4 Aug 2008 18:33:56 -0700 (PDT) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by core3.amsl.com (Postfix) with ESMTP id D2B3E3A6832 for ; Mon, 4 Aug 2008 18:33:55 -0700 (PDT) Received: from epmmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K5300FTKTP6SY@mailout3.samsung.com> for simple@ietf.org; Tue, 05 Aug 2008 10:34:18 +0900 (KST) Received: from JKOH ([10.89.26.207]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0K53009L0TP6TS@mmp1.samsung.com> for simple@ietf.org; Tue, 05 Aug 2008 10:34:18 +0900 (KST) Date: Tue, 05 Aug 2008 10:33:57 +0900 From: JaekwonOH To: Simple WG Message-id: <005001c8f69b$54282520$cf1a590a@JKOH> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal Subject: [Simple] How to show presentity's relative service preference X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0360301508==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0360301508== Content-type: multipart/alternative; boundary="Boundary_(ID_GLx3R1YhQyvLF5aTKZlwzw)" This is a multi-part message in MIME format. --Boundary_(ID_GLx3R1YhQyvLF5aTKZlwzw) Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT Hi all, I'm wondering how a presentity can show his perferred services in presence. A possibility seems to use the 'priority' attribute of element for this purpose. However, RFC 3863 defines that the 'priority' attribute shows the presentity's different preference over *contact address*, so it is not clear whether this is good enough to show the presentity's relative service preference. For example, when there are multiple SIP services that share the presentity's AOR as contact address, then how the different 'priority' attribute value for the same contact address should be interpreted? IMHO, this happens because a service cannot be represented only with the contact information. Rather, as noted in RFC 4476, a service is identified by the "reach information", which is a set of presence information to reach the service including the contact address. If this is the case, what should we do? Thanks & regards, Jaekwon OH --Boundary_(ID_GLx3R1YhQyvLF5aTKZlwzw) Content-type: text/html; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT
Hi all,
 
I'm wondering how a presentity can show his perferred services in presence.
A possibility seems to use the 'priority' attribute of <contact> element for this purpose.
However, RFC 3863 defines that the 'priority' attribute shows the presentity's different preference over *contact address*, so it is not clear whether this is good enough to show the presentity's relative service preference.
For example, when there are multiple SIP services that share the presentity's AOR as contact address, then how the different 'priority' attribute value for the same contact address should be interpreted?
IMHO, this happens because a service cannot be represented only with the contact information. Rather, as noted in RFC 4476, a service is identified by the "reach information", which is a set of presence information to reach the service including the contact address.
If this is the case, what should we do?
Thanks & regards,
 
Jaekwon OH
--Boundary_(ID_GLx3R1YhQyvLF5aTKZlwzw)-- --===============0360301508== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============0360301508==-- From simple-bounces@ietf.org Tue Aug 5 05:59:13 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1846028C251; Tue, 5 Aug 2008 05:59:13 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8F428C1C9 for ; Tue, 5 Aug 2008 05:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 PFfa2TaVqsR5 for ; Tue, 5 Aug 2008 05:59:09 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 13DBE3A6A78 for ; Tue, 5 Aug 2008 05:59:09 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 21C742079E for ; Tue, 5 Aug 2008 14:59:37 +0200 (CEST) X-AuditID: c1b4fb3e-ad997bb000004ec0-5e-48984eb926fd Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0749F203FA for ; Tue, 5 Aug 2008 14:59:37 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Aug 2008 14:59:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Aug 2008 14:59:35 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSRP-ACM: Comedia stand-alone? thread-index: Acj2+xxbS/+Ew9mmTDymF8OZqDz5hA== From: "Christer Holmberg" To: X-OriginalArrivalTime: 05 Aug 2008 12:59:36.0882 (UTC) FILETIME=[1D4C4120:01C8F6FB] X-Brightmail-Tracker: AAAAAA== Subject: [Simple] MSRP-ACM: Comedia stand-alone? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1303864059==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1303864059== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F6FB.1CD7124C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F6FB.1CD7124C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As agreed in Dublin, we are planning to set up a phone meeting regarding the alternative connection model for MSRP. But, before that I'd like to bring up one issues we need to address: should one be allowed to use comedia together with the current MSRP routing model, or will comedia and SDP c/m line routing go together? If comedia and c/m line routing go together we won't need the msrp-acm attribute defined in the draft, because the comedia attributes will act as indicators. Regards, Christer ------_=_NextPart_001_01C8F6FB.1CD7124C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MSRP-ACM: Comedia stand-alone?

Hi,

As agreed in Dublin, we are planning to = set up a phone meeting regarding the alternative connection model for = MSRP.

But, before that I'd like to bring up = one issues we need to address: should one be allowed to use comedia = together with the current MSRP routing model, or will comedia and SDP = c/m line routing go together?

If comedia and c/m line routing go = together we won't need the msrp-acm attribute defined in the draft, = because the comedia attributes will act as indicators.

Regards,

Christer


------_=_NextPart_001_01C8F6FB.1CD7124C-- --===============1303864059== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============1303864059==-- From simple-bounces@ietf.org Tue Aug 5 09:23:07 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C892428C2DA; Tue, 5 Aug 2008 09:23:07 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B8828C2D9 for ; Tue, 5 Aug 2008 09:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 5J4-FqieZJSg for ; Tue, 5 Aug 2008 09:23:05 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 3E7CD3A6967 for ; Tue, 5 Aug 2008 09:23:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,311,1215403200"; d="scan'208,217";a="117179953" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Aug 2008 12:23:34 -0400 X-IronPort-AV: E=Sophos;i="4.31,311,1215403200"; d="scan'208,217";a="251436810" Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Aug 2008 12:23:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Aug 2008 17:23:33 +0100 Message-ID: <4C607BEA097DF048BEA625B974A36618730B56@306900ANEX2.global.avaya.com> In-Reply-To: <005001c8f69b$54282520$cf1a590a@JKOH> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] How to show presentity's relative service preference Thread-Index: Acj2m3sJADVSSIIzSwGJ7ZaH7oyUIQAdNyiw References: <005001c8f69b$54282520$cf1a590a@JKOH> From: "Smyth, Colm (Colm)" To: "Simple WG" Subject: Re: [Simple] How to show presentity's relative service preference X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2023748878==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============2023748878== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F717.9A7D8906" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F717.9A7D8906 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I suggest that if there are multiple contact addresses for a single AOR, the contact element of each related tuple in PIDF should reflect a unique contact address for this AOR, not the ambiguous AOR itself. =20 A unique address is useful, not just as an identifier for the tuple's source, but to reach the address; then, the priority attribute has a meaningful scope. =20 Colm Smyth Lead/Architect - Intelligent Presence Server (IPS) | Unified Communications AVAYA | smythc@avaya.com | +353 1 656 7843 (x37843) =20 ________________________________ From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of JaekwonOH Sent: 05 August 2008 02:34 To: Simple WG Subject: [Simple] How to show presentity's relative service preference Hi all, =20 I'm wondering how a presentity can show his perferred services in presence. A possibility seems to use the 'priority' attribute of element for this purpose. However, RFC 3863 defines that the 'priority' attribute shows the presentity's different preference over *contact address*, so it is not clear whether this is good enough to show the presentity's relative service preference.=20 For example, when there are multiple SIP services that share the presentity's AOR as contact address, then how the different 'priority' attribute value for the same contact address should be interpreted? IMHO, this happens because a service cannot be represented only with the contact information. Rather, as noted in RFC 4476, a service is identified by the "reach information", which is a set of presence information to reach the service including the contact address. If this is the case, what should we do? Thanks & regards, =20 Jaekwon OH ------_=_NextPart_001_01C8F717.9A7D8906 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I suggest that if there are multiple contact = addresses=20 for a single AOR, the contact element of each related tuple in PIDF = should=20 reflect a unique contact address for this AOR, not the ambiguous AOR=20 itself.
 
A unique address is useful, not just as an = identifier=20 for the tuple's source, but to reach the address; then, the priority = attribute=20 has a meaningful scope.
 
Colm Smyth
Lead/Architect=20 - Intelligent Presence Server (IPS) | Unified=20 Communications
AVAYA | smythc@avaya.com | +353=20 1 656 7843=20 (x37843)
 

From: simple-bounces@ietf.org=20 [mailto:simple-bounces@ietf.org] On Behalf Of = JaekwonOH
Sent:=20 05 August 2008 02:34
To: Simple WG
Subject: [Simple] = How to=20 show presentity's relative service preference

Hi all,
 
I'm wondering how a = presentity can show=20 his perferred services in presence.
A possibility seems to use the = 'priority'=20 attribute of <contact> element for this purpose.
However, RFC = 3863=20 defines that the 'priority' attribute shows the presentity's different=20 preference over *contact address*, so it is not clear whether this is = good=20 enough to show the presentity's relative service preference.
For = example,=20 when there are multiple SIP services that share the presentity's AOR as = contact=20 address, then how the different 'priority' attribute value for the same = contact=20 address should be interpreted?
IMHO, this happens because a service = cannot be=20 represented only with the contact information. Rather, as noted in RFC = 4476, a=20 service is identified by the "reach information", which is a set of = presence=20 information to reach the service including the contact = address.
If this is the case, what = should we=20 do?
Thanks & regards,
 
Jaekwon = OH
------_=_NextPart_001_01C8F717.9A7D8906-- --===============2023748878== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============2023748878==-- From simple-bounces@ietf.org Wed Aug 6 21:27:56 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D5423A693F; Wed, 6 Aug 2008 21:27:56 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003603A693F for ; Wed, 6 Aug 2008 21:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 fH8aCa6EoLpn for ; Wed, 6 Aug 2008 21:27:54 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id C07B63A65A6 for ; Wed, 6 Aug 2008 21:27:54 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m774Pwkn018321; Wed, 6 Aug 2008 23:28:22 -0500 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 07:28:16 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 23:28:14 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Aug 2008 23:28:14 -0500 Message-ID: In-Reply-To: <4C607BEA097DF048BEA625B974A36618730B56@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] How to show presentity's relative service preference Thread-Index: Acj2m3sJADVSSIIzSwGJ7ZaH7oyUIQAdNyiwADszoSA= References: <005001c8f69b$54282520$cf1a590a@JKOH> <4C607BEA097DF048BEA625B974A36618730B56@306900ANEX2.global.avaya.com> From: To: , X-OriginalArrivalTime: 07 Aug 2008 04:28:14.0184 (UTC) FILETIME=[01CF9680:01C8F846] X-Nokia-AV: Clean Subject: Re: [Simple] How to show presentity's relative service preference X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1261888313==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1261888313== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F846.01DD7B38" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F846.01DD7B38 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Even though RFC 3863 is not very well written, in my understanding the priority attribute defined in RFC 3863 represents the relative priority of the service among the other services listed in the presence document. If one tuple includes multiple elements (for whatever reason...), the numerical values for the priority attributes have to be carefully chosen so that the relative priority of the service falls within the intended range. =20 Cheers, Krisztian=20 ________________________________ From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of ext Smyth, Colm (Colm) Sent: Tuesday, August 05, 2008 9:24 AM To: Simple WG Subject: Re: [Simple] How to show presentity's relative service preference =09 =09 I suggest that if there are multiple contact addresses for a single AOR, the contact element of each related tuple in PIDF should reflect a unique contact address for this AOR, not the ambiguous AOR itself. =20 A unique address is useful, not just as an identifier for the tuple's source, but to reach the address; then, the priority attribute has a meaningful scope. =20 Colm Smyth Lead/Architect - Intelligent Presence Server (IPS) | Unified Communications AVAYA | smythc@avaya.com | +353 1 656 7843 (x37843) =20 ________________________________ From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of JaekwonOH Sent: 05 August 2008 02:34 To: Simple WG Subject: [Simple] How to show presentity's relative service preference =09 =09 Hi all, =20 I'm wondering how a presentity can show his perferred services in presence. A possibility seems to use the 'priority' attribute of element for this purpose. However, RFC 3863 defines that the 'priority' attribute shows the presentity's different preference over *contact address*, so it is not clear whether this is good enough to show the presentity's relative service preference.=20 For example, when there are multiple SIP services that share the presentity's AOR as contact address, then how the different 'priority' attribute value for the same contact address should be interpreted? IMHO, this happens because a service cannot be represented only with the contact information. Rather, as noted in RFC 4476, a service is identified by the "reach information", which is a set of presence information to reach the service including the contact address. If this is the case, what should we do? =09 =09 Thanks & regards, =20 Jaekwon OH ------_=_NextPart_001_01C8F846.01DD7B38 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Even though RFC 3863 is not very well written, = in my=20 understanding the priority attribute defined in RFC = 3863=20 represents the relative priority of the service among the other services = listed=20 in the presence document. If one tuple includes multiple <contact> = elements (for whatever reason...), the numerical values for the priority = attributes have to be carefully chosen so that the relative priority of = the=20 service falls within the intended range.
 
Cheers,
Krisztian 

From: simple-bounces@ietf.org=20 [mailto:simple-bounces@ietf.org] On Behalf Of ext Smyth, Colm=20 (Colm)
Sent: Tuesday, August 05, 2008 9:24 AM
To: = Simple=20 WG
Subject: Re: [Simple] How to show presentity's relative = service=20 preference

I suggest that if there are multiple = contact=20 addresses for a single AOR, the contact element of each related tuple = in PIDF=20 should reflect a unique contact address for this AOR, not the = ambiguous AOR=20 itself.
 
A unique address is useful, not just as an = identifier=20 for the tuple's source, but to reach the address; then, the priority = attribute=20 has a meaningful scope.
 
Colm Smyth
Lead/Architect=20 - Intelligent Presence Server (IPS) | Unified=20 Communications
AVAYA | smythc@avaya.com | +353=20 1 656 7843 = (x37843)
 

From: simple-bounces@ietf.org=20 [mailto:simple-bounces@ietf.org] On Behalf Of = JaekwonOH
Sent:=20 05 August 2008 02:34
To: Simple WG
Subject: = [Simple] How=20 to show presentity's relative service preference

Hi all,
 
I'm wondering how a = presentity can=20 show his perferred services in presence.
A possibility seems to use = the=20 'priority' attribute of <contact> element for this = purpose.
However,=20 RFC 3863 defines that the 'priority' attribute shows the presentity's=20 different preference over *contact address*, so it is not clear = whether this=20 is good enough to show the presentity's relative service preference. =
For=20 example, when there are multiple SIP services that share the = presentity's AOR=20 as contact address, then how the different 'priority' attribute value = for the=20 same contact address should be interpreted?
IMHO, this happens = because a=20 service cannot be represented only with the contact information. = Rather, as=20 noted in RFC 4476, a service is identified by the "reach information", = which=20 is a set of presence information to reach the service including the = contact=20 address.
If this is the case, what = should we=20 do?
Thanks & = regards,
 
Jaekwon=20 OH
------_=_NextPart_001_01C8F846.01DD7B38-- --===============1261888313== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============1261888313==-- From simple-bounces@ietf.org Wed Aug 6 22:17:36 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D733A6808; Wed, 6 Aug 2008 22:17:36 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3C433A6808 for ; Wed, 6 Aug 2008 22:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=-1.669, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_203=0.994] 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 mlEzwrT5D6jv for ; Wed, 6 Aug 2008 22:17:33 -0700 (PDT) Received: from mailout5.samsung.com (mailout5.samsung.com [203.254.224.35]) by core3.amsl.com (Postfix) with ESMTP id 44A8B3A679F for ; Wed, 6 Aug 2008 22:17:32 -0700 (PDT) Received: from epmmp2 (mailout5.samsung.com [203.254.224.35]) by mailout5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K5700FWLTDXQE@mailout5.samsung.com> for simple@ietf.org; Thu, 07 Aug 2008 14:17:57 +0900 (KST) Received: from JKOH ([10.89.26.207]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0K5700BATTDWVP@mmp2.samsung.com> for simple@ietf.org; Thu, 07 Aug 2008 14:17:56 +0900 (KST) Date: Thu, 07 Aug 2008 14:17:48 +0900 From: JaekwonOH To: Simple WG , "Smyth, Colm (Colm)" Message-id: <012301c8f84c$eeeb9a80$cf1a590a@JKOH> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <005001c8f69b$54282520$cf1a590a@JKOH> <4C607BEA097DF048BEA625B974A36618730B56@306900ANEX2.global.avaya.com> Subject: Re: [Simple] How to show presentity's relative service preference X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0942185061==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0942185061== Content-type: multipart/alternative; boundary="Boundary_(ID_y+wjzV0aB3S45P3oolNVlA)" This is a multi-part message in MIME format. --Boundary_(ID_y+wjzV0aB3S45P3oolNVlA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, Thanks for response. Even when the device contact URI registered for an AOR is used for tuple's contact address, the uniqueness of the contact address for a tupe seems not guaranteed. For example, a device may run multiple SIP applications, then tuples for each of those would contain the same URI. This aspect has already been clarified in RFC 4479 (see the following excerption). Therefore, IMHO, the uniquness of contact address for each tuple seem not guaranteed, so the use of 'priority' attribute of in is not enogh to show the presenity's relative service preference. >From RFC 4479 section 3.3.2 reach information, Even for services reachable over a communications network, the URI alone may not be sufficient. For example, two applications may be running within a cellular telephone, both of which are reachable through the user's SIP Address of Record. However, one application is launched when the INVITE request contains a body of a particular type, and the other is launched for other body types. As another example, a service may provide complex application logic that operates correctly only when contacted from matching application software. In such a case, even though the communications between instances utilizes a standard protocol (such as SIP), the user experience will not be correct unless the applications are matched. When the URI is not sufficient, additional attributes of the service can be present that define the instructions on how the service is to be reached. These attributes must be understood for the service to be utilized. If a watcher receives a presence document containing reach information it does not understand, it should discard the service information. Thanks & regards, Jaekwon OH ----- Original Message ----- From: Smyth, Colm (Colm) To: Simple WG Sent: Wednesday, August 06, 2008 1:23 AM Subject: Re: [Simple] How to show presentity's relative service preference I suggest that if there are multiple contact addresses for a single AOR, the contact element of each related tuple in PIDF should reflect a unique contact address for this AOR, not the ambiguous AOR itself. A unique address is useful, not just as an identifier for the tuple's source, but to reach the address; then, the priority attribute has a meaningful scope. Colm Smyth Lead/Architect - Intelligent Presence Server (IPS) | Unified Communications AVAYA | smythc@avaya.com | +353 1 656 7843 (x37843) ------------------------------------------------------------------------------ From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of JaekwonOH Sent: 05 August 2008 02:34 To: Simple WG Subject: [Simple] How to show presentity's relative service preference Hi all, I'm wondering how a presentity can show his perferred services in presence. A possibility seems to use the 'priority' attribute of element for this purpose. However, RFC 3863 defines that the 'priority' attribute shows the presentity's different preference over *contact address*, so it is not clear whether this is good enough to show the presentity's relative service preference. For example, when there are multiple SIP services that share the presentity's AOR as contact address, then how the different 'priority' attribute value for the same contact address should be interpreted? IMHO, this happens because a service cannot be represented only with the contact information. Rather, as noted in RFC 4476, a service is identified by the "reach information", which is a set of presence information to reach the service including the contact address. If this is the case, what should we do? Thanks & regards, Jaekwon OH ------------------------------------------------------------------------------ _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --Boundary_(ID_y+wjzV0aB3S45P3oolNVlA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuNjAwMC4xNjY3NCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpLDwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPlRoYW5rcyBmb3IgcmVzcG9uc2UuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+RXZlbiZuYnNwO3doZW4mbmJzcDt0aGUgZGV2aWNlIGNvbnRhY3QgVVJJIHJlZ2lzdGVyZWQg Zm9yIGFuIA0KQU9SJm5ic3A7aXMgdXNlZCBmb3IgdHVwbGUncyBjb250YWN0IGFkZHJlc3MsIHRo ZSB1bmlxdWVuZXNzIG9mIHRoZSBjb250YWN0IA0KYWRkcmVzcyBmb3IgYSB0dXBlIHNlZW1zIG5v dCBndWFyYW50ZWVkLiBGb3IgZXhhbXBsZSwmbmJzcDthIGRldmljZSBtYXkgDQpydW4mbmJzcDtt dWx0aXBsZSBTSVAgYXBwbGljYXRpb25zLCB0aGVuIHR1cGxlcyBmb3IgZWFjaCBvZiB0aG9zZSB3 b3VsZCBjb250YWluIA0KdGhlIHNhbWUgVVJJLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPlRoaXMgYXNwZWN0IGhhcyBhbHJlYWR5IGJlZW4gY2xhcmlmaWVkIGluIFJGQyA0NDc5IChz ZWUgdGhlIA0KZm9sbG93aW5nIGV4Y2VycHRpb24pLjwvRk9OVD48L0RJVj4NCjxESVY+DQo8RElW PjxGT05UIHNpemU9Mj5UaGVyZWZvcmUsIElNSE8sIHRoZSB1bmlxdW5lc3Mgb2YgY29udGFjdCBh ZGRyZXNzIGZvciBlYWNoIA0KdHVwbGUgc2VlbSBub3QgZ3VhcmFudGVlZCwgc28mbmJzcDt0aGUg dXNlIG9mICdwcmlvcml0eScgYXR0cmlidXRlIG9mIA0KJmx0O2NvbnRhY3QmZ3Q7IGluICZsdDt0 dXBsZSZndDsgaXMgbm90IGVub2doIHRvIHNob3cgdGhlIHByZXNlbml0eSdzIHJlbGF0aXZlIA0K c2VydmljZSBwcmVmZXJlbmNlLjwvRk9OVD48L0RJVj48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkZyb20gUkZDIDQ0NzkmbmJz cDtzZWN0aW9uIDMuMy4yIHJlYWNoIA0KaW5mb3JtYXRpb24sPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+RXZlbiBm b3Igc2VydmljZXMgcmVhY2hhYmxlIG92ZXIgYSBjb21tdW5pY2F0aW9ucyBuZXR3b3JrLCB0aGUg DQpVUkk8QlI+YWxvbmUgbWF5IG5vdCBiZSBzdWZmaWNpZW50LiBGb3IgZXhhbXBsZSwgdHdvIGFw cGxpY2F0aW9ucyBtYXkgDQpiZTxCUj5ydW5uaW5nIHdpdGhpbiBhIGNlbGx1bGFyIHRlbGVwaG9u ZSwgYm90aCBvZiB3aGljaCBhcmUgDQpyZWFjaGFibGU8QlI+dGhyb3VnaCB0aGUgdXNlcpJzIFNJ UCBBZGRyZXNzIG9mIFJlY29yZC4gSG93ZXZlciwgb25lIA0KYXBwbGljYXRpb248QlI+aXMgbGF1 bmNoZWQgd2hlbiB0aGUgSU5WSVRFIHJlcXVlc3QgY29udGFpbnMgYSBib2R5IG9mIGEgDQpwYXJ0 aWN1bGFyPEJSPnR5cGUsIGFuZCB0aGUgb3RoZXIgaXMgbGF1bmNoZWQgZm9yIG90aGVyIGJvZHkg dHlwZXMuIEFzIA0KYW5vdGhlcjxCUj5leGFtcGxlLCBhIHNlcnZpY2UgbWF5IHByb3ZpZGUgY29t cGxleCBhcHBsaWNhdGlvbiBsb2dpYyANCnRoYXQ8QlI+b3BlcmF0ZXMgY29ycmVjdGx5IG9ubHkg d2hlbiBjb250YWN0ZWQgZnJvbSBtYXRjaGluZyANCmFwcGxpY2F0aW9uPEJSPnNvZnR3YXJlLiBJ biBzdWNoIGEgY2FzZSwgZXZlbiB0aG91Z2ggdGhlIGNvbW11bmljYXRpb25zIA0KYmV0d2VlbjxC Uj5pbnN0YW5jZXMgdXRpbGl6ZXMgYSBzdGFuZGFyZCBwcm90b2NvbCAoc3VjaCBhcyBTSVApLCB0 aGUgDQp1c2VyPEJSPmV4cGVyaWVuY2Ugd2lsbCBub3QgYmUgY29ycmVjdCB1bmxlc3MgdGhlIGFw cGxpY2F0aW9ucyBhcmUgDQptYXRjaGVkLjxCUj5XaGVuIHRoZSBVUkkgaXMgbm90IHN1ZmZpY2ll bnQsIGFkZGl0aW9uYWwgYXR0cmlidXRlcyBvZiB0aGUgDQpzZXJ2aWNlPEJSPmNhbiBiZSBwcmVz ZW50IHRoYXQgZGVmaW5lIHRoZSBpbnN0cnVjdGlvbnMgb24gaG93IHRoZSBzZXJ2aWNlIGlzIA0K dG88QlI+YmUgcmVhY2hlZC4gVGhlc2UgYXR0cmlidXRlcyBtdXN0IGJlIHVuZGVyc3Rvb2QgZm9y IHRoZSBzZXJ2aWNlIHRvPEJSPmJlIA0KdXRpbGl6ZWQuIElmIGEgd2F0Y2hlciByZWNlaXZlcyBh IHByZXNlbmNlIGRvY3VtZW50IGNvbnRhaW5pbmc8QlI+cmVhY2ggDQppbmZvcm1hdGlvbiBpdCBk b2VzIG5vdCB1bmRlcnN0YW5kLCBpdCBzaG91bGQgZGlzY2FyZCB0aGU8QlI+c2VydmljZSANCmlu Zm9ybWF0aW9uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPlRoYW5rcyAmYW1wOyByZWdhcmRzLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPkphZWt3b24gT0g8QlI+PC9GT05UPjwvRElWPg0KPERJVj4tLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tIDwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4 OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAw MDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgDQogIHN0eWxlPSJCQUNL R1JPVU5EOiAjZTRlNGU0OyBGT05UOiAxMHB0ICYjNDQ0MDQ7JiM0NzU0ODs7IGZvbnQtY29sb3I6 IGJsYWNrIj48Qj5Gcm9tOjwvQj4gPEEgDQogIHRpdGxlPXNteXRoY0BhdmF5YS5jb20gaHJlZj0i bWFpbHRvOnNteXRoY0BhdmF5YS5jb20iPlNteXRoLCBDb2xtIChDb2xtKTwvQT4gDQogIDwvRElW Pg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0ICYjNDQ0MDQ7JiM0NzU0ODsiPjxCPlRvOjwvQj4g PEEgdGl0bGU9c2ltcGxlQGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86c2ltcGxlQGlldGYub3Jn Ij5TaW1wbGUgV0c8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0ICYjNDQ0MDQ7 JiM0NzU0ODsiPjxCPlNlbnQ6PC9CPiBXZWRuZXNkYXksIEF1Z3VzdCAwNiwgMjAwOCAxOjIzIA0K ICBBTTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0ICYjNDQ0MDQ7JiM0NzU0ODsiPjxC PlN1YmplY3Q6PC9CPiBSZTogW1NpbXBsZV0gSG93IHRvIHNob3cgDQogIHByZXNlbnRpdHkncyBy ZWxhdGl2ZSBzZXJ2aWNlIHByZWZlcmVuY2U8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxE SVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXpl PTI+PFNQQU4gDQogIGNsYXNzPTI3NjM0MzExNS0wNTA4MjAwOD5JIHN1Z2dlc3QgdGhhdCBpZiB0 aGVyZSBhcmUgbXVsdGlwbGUgY29udGFjdCANCiAgYWRkcmVzc2VzIGZvciBhIHNpbmdsZSBBT1Is IHRoZSBjb250YWN0IGVsZW1lbnQgb2YgZWFjaCByZWxhdGVkIHR1cGxlIGluIFBJREYgDQogIHNo b3VsZCByZWZsZWN0IGEgdW5pcXVlIGNvbnRhY3QgYWRkcmVzcyBmb3IgdGhpcyBBT1IsIG5vdCB0 aGUgYW1iaWd1b3VzIEFPUiANCiAgaXRzZWxmLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVYg ZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+ PFNQQU4gDQogIGNsYXNzPTI3NjM0MzExNS0wNTA4MjAwOD48L1NQQU4+PC9GT05UPiZuYnNwOzwv RElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0yNzYzNDMxMTUtMDUwODIwMDg+QSB1bmlxdWUg YWRkcmVzcyBpcyB1c2VmdWwsIG5vdCBqdXN0IGFzIGFuIGlkZW50aWZpZXIgDQogIGZvciB0aGUg dHVwbGUncyBzb3VyY2UsIGJ1dCB0byByZWFjaCB0aGUgYWRkcmVzczsgdGhlbiwgdGhlIHByaW9y aXR5IGF0dHJpYnV0ZSANCiAgaGFzIGEgbWVhbmluZ2Z1bCBzY29wZS48L1NQQU4+PC9GT05UPjwv RElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPg0KICA8RElWIGFsaWduPWxlZnQ+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IENPTE9SOiBncmF5OyBGT05ULUZBTUlMWTogJ0NlbnR1cnkgR290aGljJywnc2Fu cy1zZXJpZiciPjxGT05UIA0KICBmYWNlPUFyaWFsPkNvbG0gU215dGg8L0ZPTlQ+PC9TUEFOPjwv RElWPg0KICA8RElWIGFsaWduPWxlZnQ+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IENPTE9SOiBncmF5OyBGT05ULUZBTUlMWTogJ0NlbnR1cnkgR290aGljJywnc2Fucy1zZXJpZici PjwvU1BBTj48Rk9OVCANCiAgc2l6ZT0xPjxGT05UIGZhY2U9QXJpYWw+PFNQQU4gDQogIHN0eWxl PSJGT05ULVNJWkU6IDcuNXB0OyBDT0xPUjogZ3JheTsgRk9OVC1GQU1JTFk6ICdDZW50dXJ5IEdv dGhpYycsJ3NhbnMtc2VyaWYnIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogNy41cHQ7IENP TE9SOiBncmF5OyBGT05ULUZBTUlMWTogJ0NlbnR1cnkgR290aGljJywnc2Fucy1zZXJpZiciPkxl YWQvQXJjaGl0ZWN0IA0KICAtIEludGVsbGlnZW50IFByZXNlbmNlIFNlcnZlciAoSVBTKTwvU1BB Tj4gPEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jZmYwMDAwIA0KICBzaXplPTE+fDwvRk9OVD4mbmJz cDs8U1BBTiBjbGFzcz0yNzYzNDMxMTUtMDUwODIwMDg+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29s b3I9I2ZmMDAwMCBzaXplPTE+VW5pZmllZCANCiAgQ29tbXVuaWNhdGlvbnM8L0ZPTlQ+PC9TUEFO PjwvU1BBTj48L0ZPTlQ+PC9GT05UPjxTUEFOIA0KICBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05U LUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJyI+PEJSPjwvU1BBTj48Rk9OVCANCiAg c2l6ZT0xPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgDQogIGNvbG9yPSNmZjAwMDA+PFNQQU4+PFNU Uk9ORz5BVkFZQTwvU1RST05HPiZuYnNwO3w8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJ WkU6IDcuNXB0OyBDT0xPUjogZ3JlZW47IEZPTlQtRkFNSUxZOiAnQ2VudHVyeSBHb3RoaWMnLCdz YW5zLXNlcmlmJyI+PEZPTlQgDQogIGZhY2U9QXJpYWwgc2l6ZT0xPiZuYnNwOzwvRk9OVD48L1NQ QU4+PC9GT05UPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiA3LjVwdDsgQ09MT1I6IGdyZWVu OyBGT05ULUZBTUlMWTogJ0NlbnR1cnkgR290aGljJywnc2Fucy1zZXJpZiciPjxBIA0KICBocmVm PSJtYWlsdG86c215dGhjQGF2YXlhLmNvbSI+c215dGhjQGF2YXlhLmNvbTwvQT4mbmJzcDs8Rk9O VCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jZmYwMDAwIHNpemU9MT58PC9GT05UPjwvU1BBTj48U1BB TiANCiAgc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4n LCdzZXJpZiciPiZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogNy41cHQ7 IENPTE9SOiBncmF5OyBGT05ULUZBTUlMWTogJ0NlbnR1cnkgR290aGljJywnc2Fucy1zZXJpZici PiszNTMgDQogIDEgNjU2IDc4NDM8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJDT0xPUjogYmxhY2s7 IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnIj48L1NQQU4+IA0KICA8L0ZP TlQ+PEZPTlQgZmFjZT0iQ2VudHVyeSBHb3RoaWMiIGNvbG9yPSM4MDgwODA+KHgzNzg0Myk8L0ZP TlQ+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjxCUj4NCiAgPERJViBjbGFzcz1PdXRsb29rTWVzc2Fn ZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4NCiAgPEhSIHRhYkluZGV4PS0x Pg0KICA8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IHNpbXBsZS1ib3VuY2Vz QGlldGYub3JnIA0KICBbbWFpbHRvOnNpbXBsZS1ib3VuY2VzQGlldGYub3JnXSA8Qj5PbiBCZWhh bGYgT2YgPC9CPkphZWt3b25PSDxCUj48Qj5TZW50OjwvQj4gDQogIDA1IEF1Z3VzdCAyMDA4IDAy OjM0PEJSPjxCPlRvOjwvQj4gU2ltcGxlIFdHPEJSPjxCPlN1YmplY3Q6PC9CPiBbU2ltcGxlXSBI b3cgDQogIHRvIHNob3cgcHJlc2VudGl0eSdzIHJlbGF0aXZlIHNlcnZpY2UgcHJlZmVyZW5jZTxC Uj48L0ZPTlQ+PEJSPjwvRElWPg0KICA8RElWPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IlRp bWVzIE5ldyBSb21hbiIgc2l6ZT0yPkhpIGFsbCw8L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElW PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0yPkknbSB3b25kZXJpbmcgaG93IGEg cHJlc2VudGl0eSBjYW4gDQogIHNob3cgaGlzIHBlcmZlcnJlZCBzZXJ2aWNlcyBpbiBwcmVzZW5j ZS48QlI+QSBwb3NzaWJpbGl0eSBzZWVtcyB0byB1c2UgdGhlIA0KICAncHJpb3JpdHknIGF0dHJp YnV0ZSBvZiAmbHQ7Y29udGFjdCZndDsgZWxlbWVudCBmb3IgdGhpcyBwdXJwb3NlLjxCUj5Ib3dl dmVyLCANCiAgUkZDIDM4NjMgZGVmaW5lcyB0aGF0IHRoZSAncHJpb3JpdHknIGF0dHJpYnV0ZSBz aG93cyB0aGUgcHJlc2VudGl0eSdzIA0KICBkaWZmZXJlbnQgcHJlZmVyZW5jZSBvdmVyICpjb250 YWN0IGFkZHJlc3MqLCBzbyBpdCBpcyBub3QgY2xlYXIgd2hldGhlciB0aGlzIA0KICBpcyBnb29k IGVub3VnaCB0byBzaG93IHRoZSBwcmVzZW50aXR5J3MgcmVsYXRpdmUgc2VydmljZSBwcmVmZXJl bmNlLiA8QlI+Rm9yIA0KICBleGFtcGxlLCB3aGVuIHRoZXJlIGFyZSBtdWx0aXBsZSBTSVAgc2Vy dmljZXMgdGhhdCBzaGFyZSB0aGUgcHJlc2VudGl0eSdzIEFPUiANCiAgYXMgY29udGFjdCBhZGRy ZXNzLCB0aGVuIGhvdyB0aGUgZGlmZmVyZW50ICdwcmlvcml0eScgYXR0cmlidXRlIHZhbHVlIGZv ciB0aGUgDQogIHNhbWUgY29udGFjdCBhZGRyZXNzIHNob3VsZCBiZSBpbnRlcnByZXRlZD88QlI+ SU1ITywgdGhpcyBoYXBwZW5zIGJlY2F1c2UgYSANCiAgc2VydmljZSBjYW5ub3QgYmUgcmVwcmVz ZW50ZWQgb25seSB3aXRoIHRoZSBjb250YWN0IGluZm9ybWF0aW9uLiBSYXRoZXIsIGFzIA0KICBu b3RlZCBpbiBSRkMgNDQ3NiwgYSBzZXJ2aWNlIGlzIGlkZW50aWZpZWQgYnkgdGhlICJyZWFjaCBp bmZvcm1hdGlvbiIsIHdoaWNoIA0KICBpcyBhIHNldCBvZiBwcmVzZW5jZSBpbmZvcm1hdGlvbiB0 byByZWFjaCB0aGUgc2VydmljZSBpbmNsdWRpbmcgdGhlIGNvbnRhY3QgDQogIGFkZHJlc3MuPC9G T05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0yPklm IHRoaXMgaXMgdGhlIGNhc2UsIHdoYXQgc2hvdWxkIHdlIA0KICBkbz88QlI+PC9ESVY+PC9GT05U PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0yPjwvRk9OVD4NCiAgPERJVj48Rk9O VCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mj5UaGFua3MgJmFtcDsgcjwvRk9OVD48Rk9O VCANCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTI+ZWdhcmRzLDwvRk9OVD48L0RJVj4N CiAgPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTI+SmFla3dv biBPSDwvRk9OVD48L0RJVj4NCiAgPFA+DQogIDxIUj4NCg0KICA8UD48L1A+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+U2ltcGxlIG1haWxpbmcgDQog IGxpc3Q8QlI+U2ltcGxlQGlldGYub3JnPEJSPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ltcGxlPEJSPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_y+wjzV0aB3S45P3oolNVlA)-- --===============0942185061== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============0942185061==-- From simple-bounces@ietf.org Wed Aug 6 23:25:27 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93A973A6874; Wed, 6 Aug 2008 23:25:27 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4323A6874 for ; Wed, 6 Aug 2008 23:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=2.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] 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 WzncD0nIk0Wp for ; Wed, 6 Aug 2008 23:25:25 -0700 (PDT) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by core3.amsl.com (Postfix) with ESMTP id 4C84B3A67AF for ; Wed, 6 Aug 2008 23:25:25 -0700 (PDT) Received: from epmmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K5700FEOWJ6Y2@mailout3.samsung.com> for simple@ietf.org; Thu, 07 Aug 2008 15:25:54 +0900 (KST) Received: from JKOH ([10.89.26.207]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0K5700HUXWJ6A5@mmp1.samsung.com> for simple@ietf.org; Thu, 07 Aug 2008 15:25:54 +0900 (KST) Date: Thu, 07 Aug 2008 15:25:46 +0900 From: JaekwonOH To: simple@ietf.org, smythc@avaya.com, krisztian.kiss@nokia.com Message-id: <018e01c8f856$6d5fcd10$cf1a590a@JKOH> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <005001c8f69b$54282520$cf1a590a@JKOH> <4C607BEA097DF048BEA625B974A36618730B56@306900ANEX2.global.avaya.com> Subject: Re: [Simple] How to show presentity's relative service preference X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0897447759==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0897447759== Content-type: multipart/alternative; boundary="Boundary_(ID_AtFKbAoYJ1SGoAM/4np2qg)" This is a multi-part message in MIME format. --Boundary_(ID_AtFKbAoYJ1SGoAM/4np2qg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Krisztian, Thanks for response. Please find below my response: Even though RFC 3863 is not very well written, in my understanding the priority attribute defined in RFC 3863 represents the relative priority of the service among the other services listed in the presence document. Your understanding expands the semantics defined in RFC 3863 on the priority attribute. Problem is that there's no clarification on such interpretation. If one tuple includes multiple elements (for whatever reason...), the numerical values for the priority attributes have to be carefully chosen so that the relative priority of the service falls within the intended range. Fortunately, the schema definition in RFC 3863 allows the element under to occur just once (or zero). So, we could get free of this issue.. Thanks & regards, Jaekwon OH ----- Original Message ----- From: krisztian.kiss@nokia.com To: smythc@avaya.com ; simple@ietf.org Sent: Thursday, August 07, 2008 1:28 PM Subject: Re: [Simple] How to show presentity's relative service preference Even though RFC 3863 is not very well written, in my understanding the priority attribute defined in RFC 3863 represents the relative priority of the service among the other services listed in the presence document. If one tuple includes multiple elements (for whatever reason...), the numerical values for the priority attributes have to be carefully chosen so that the relative priority of the service falls within the intended range. Cheers, Krisztian ---------------------------------------------------------------------------- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of ext Smyth, Colm (Colm) Sent: Tuesday, August 05, 2008 9:24 AM To: Simple WG Subject: Re: [Simple] How to show presentity's relative service preference I suggest that if there are multiple contact addresses for a single AOR, the contact element of each related tuple in PIDF should reflect a unique contact address for this AOR, not the ambiguous AOR itself. A unique address is useful, not just as an identifier for the tuple's source, but to reach the address; then, the priority attribute has a meaningful scope. Colm Smyth Lead/Architect - Intelligent Presence Server (IPS) | Unified Communications AVAYA | smythc@avaya.com | +353 1 656 7843 (x37843) ---------------------------------------------------------------------------- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of JaekwonOH Sent: 05 August 2008 02:34 To: Simple WG Subject: [Simple] How to show presentity's relative service preference Hi all, I'm wondering how a presentity can show his perferred services in presence. A possibility seems to use the 'priority' attribute of element for this purpose. However, RFC 3863 defines that the 'priority' attribute shows the presentity's different preference over *contact address*, so it is not clear whether this is good enough to show the presentity's relative service preference. For example, when there are multiple SIP services that share the presentity's AOR as contact address, then how the different 'priority' attribute value for the same contact address should be interpreted? IMHO, this happens because a service cannot be represented only with the contact information. Rather, as noted in RFC 4476, a service is identified by the "reach information", which is a set of presence information to reach the service including the contact address. If this is the case, what should we do? Thanks & regards, Jaekwon OH ------------------------------------------------------------------------------ _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --Boundary_(ID_AtFKbAoYJ1SGoAM/4np2qg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Krisztian,
 
Thanks for response. Please find below my response:
 
Even though RFC 3863 is not very well written, in my understanding the priority attribute defined in RFC 3863 represents the relative priority of the service among the other services listed in the presence document.
 
Your understanding expands the semantics defined in RFC 3863 on the priority attribute. 
Problem is that there's no clarification on such interpretation. 
 
If one tuple includes multiple <contact> elements (for whatever reason...), the numerical values for the priority attributes have to be carefully chosen so that the relative priority of the service falls within the intended range.
 
Fortunately, the schema definition in RFC 3863 allows the <contact> element under <tuple> to occur just once (or zero). So, we could get free of this issue..
 
Thanks & regards,
Jaekwon OH
----- Original Message -----
Sent: Thursday, August 07, 2008 1:28 PM
Subject: Re: [Simple] How to show presentity's relative service preference

Even though RFC 3863 is not very well written, in my understanding the priority attribute defined in RFC 3863 represents the relative priority of the service among the other services listed in the presence document.
If one tuple includes multiple <contact> elements (for whatever reason...), the numerical values for the priority attributes have to be carefully chosen so that the relative priority of the service falls within the intended range.
 
Cheers,
Krisztian 

From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of ext Smyth, Colm (Colm)
Sent: Tuesday, August 05, 2008 9:24 AM
To: Simple WG
Subject: Re: [Simple] How to show presentity's relative service preference

I suggest that if there are multiple contact addresses for a single AOR, the contact element of each related tuple in PIDF should reflect a unique contact address for this AOR, not the ambiguous AOR itself.
 
A unique address is useful, not just as an identifier for the tuple's source, but to reach the address; then, the priority attribute has a meaningful scope.
 
Colm Smyth
Lead/Architect - Intelligent Presence Server (IPS) | Unified Communications
AVAYA | smythc@avaya.com | +353 1 656 7843 (x37843)
 

From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of JaekwonOH
Sent: 05 August 2008 02:34
To: Simple WG
Subject: [Simple] How to show presentity's relative service preference

Hi all,
 
I'm wondering how a presentity can show his perferred services in presence.
A possibility seems to use the 'priority' attribute of <contact> element for this purpose.
However, RFC 3863 defines that the 'priority' attribute shows the presentity's different preference over *contact address*, so it is not clear whether this is good enough to show the presentity's relative service preference.
For example, when there are multiple SIP services that share the presentity's AOR as contact address, then how the different 'priority' attribute value for the same contact address should be interpreted?
IMHO, this happens because a service cannot be represented only with the contact information. Rather, as noted in RFC 4476, a service is identified by the "reach information", which is a set of presence information to reach the service including the contact address.
If this is the case, what should we do?
Thanks & regards,
 
Jaekwon OH

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple
--Boundary_(ID_AtFKbAoYJ1SGoAM/4np2qg)-- --===============0897447759== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============0897447759==-- From simple-bounces@ietf.org Thu Aug 7 04:47:45 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DED283A6B85; Thu, 7 Aug 2008 04:47:45 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E9E23A6B85 for ; Thu, 7 Aug 2008 04:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 mzwZSxenKX8s for ; Thu, 7 Aug 2008 04:47:43 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3442C3A6830 for ; Thu, 7 Aug 2008 04:47:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,319,1215388800"; d="scan'208";a="16775839" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Aug 2008 11:48:14 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m77BmE5e011246; Thu, 7 Aug 2008 07:48:14 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m77BmECk007135; Thu, 7 Aug 2008 11:48:14 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 07:48:14 -0400 Received: from [10.86.240.110] ([10.86.240.110]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 07:48:14 -0400 Message-ID: <489AE135.4050000@cisco.com> Date: Thu, 07 Aug 2008 07:49:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: JaekwonOH References: <005001c8f69b$54282520$cf1a590a@JKOH> <4C607BEA097DF048BEA625B974A36618730B56@306900ANEX2.global.avaya.com> <012301c8f84c$eeeb9a80$cf1a590a@JKOH> In-Reply-To: <012301c8f84c$eeeb9a80$cf1a590a@JKOH> X-OriginalArrivalTime: 07 Aug 2008 11:48:14.0100 (UTC) FILETIME=[79631540:01C8F883] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5023; t=1218109694; x=1218973694; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20How=20to=20show=20presentity 's=20relative=20service=20preference |Sender:=20 |To:=20JaekwonOH=20; bh=1fxt1MHPz+v7O4T7w9Snp4rpVK9aBAqlZuYN7ok0hLE=; b=CPV0DzFrWGJVEu/btmE/xzGmqDAVddmYMqLrakApyneDgAHqw5fCEpyqcM TiZm/LEcFKIU0+uPx8SEGYOo43rLAEvWfmC962KjHAkg/vYBG+H9uu29MOiL LPmQ+5v8Zx; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Simple WG Subject: Re: [Simple] How to show presentity's relative service preference X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org JaekwonOH wrote: > Hi, > = > Thanks for response. > Even when the device contact URI registered for an AOR is used for = > tuple's contact address, the uniqueness of the contact address for a = > tupe seems not guaranteed. For example, a device may run multiple SIP = > applications, then tuples for each of those would contain the same URI. Only if it wants them to. It certainly may use a separate contact uri = for each application. (They probably have the same address and are = distinguished by the user part, or port.) Its the responsibility of the = application to put in enough uniqueness to get proper results. Paul > This aspect has already been clarified in RFC 4479 (see the following = > excerption). > Therefore, IMHO, the uniquness of contact address for each tuple seem = > not guaranteed, so the use of 'priority' attribute of in = > is not enogh to show the presenity's relative service preference. > = > From RFC 4479 section 3.3.2 reach information, > = > Even for services reachable over a communications network, the URI > alone may not be sufficient. For example, two applications may be > running within a cellular telephone, both of which are reachable > through the user=92s SIP Address of Record. However, one application > is launched when the INVITE request contains a body of a particular > type, and the other is launched for other body types. As another > example, a service may provide complex application logic that > operates correctly only when contacted from matching application > software. In such a case, even though the communications between > instances utilizes a standard protocol (such as SIP), the user > experience will not be correct unless the applications are matched. > When the URI is not sufficient, additional attributes of the service > can be present that define the instructions on how the service is to > be reached. These attributes must be understood for the service to > be utilized. If a watcher receives a presence document containing > reach information it does not understand, it should discard the > service information. > = > = > Thanks & regards, > Jaekwon OH > ----- Original Message ----- > = > *From:* Smyth, Colm (Colm) > *To:* Simple WG > *Sent:* Wednesday, August 06, 2008 1:23 AM > *Subject:* Re: [Simple] How to show presentity's relative service > preference > = > I suggest that if there are multiple contact addresses for a single > AOR, the contact element of each related tuple in PIDF should > reflect a unique contact address for this AOR, not the ambiguous AOR > itself. > = > A unique address is useful, not just as an identifier for the > tuple's source, but to reach the address; then, the priority > attribute has a meaningful scope. > = > Colm Smyth > Lead/Architect - Intelligent Presence Server (IPS) | Unified > Communications > *AVAYA* | smythc@avaya.com | +353 1 656 > 7843 (x37843) > = > = > ---------------------------------------------------------------------= --- > *From:* simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] *On > Behalf Of *JaekwonOH > *Sent:* 05 August 2008 02:34 > *To:* Simple WG > *Subject:* [Simple] How to show presentity's relative service prefere= nce > = > Hi all, > = > I'm wondering how a presentity can show his perferred services in > presence. > A possibility seems to use the 'priority' attribute of > element for this purpose. > However, RFC 3863 defines that the 'priority' attribute shows the > presentity's different preference over *contact address*, so it is > not clear whether this is good enough to show the presentity's > relative service preference. > For example, when there are multiple SIP services that share the > presentity's AOR as contact address, then how the different > 'priority' attribute value for the same contact address should be > interpreted? > IMHO, this happens because a service cannot be represented only with > the contact information. Rather, as noted in RFC 4476, a service is > identified by the "reach information", which is a set of presence > information to reach the service including the contact address. > If this is the case, what should we do? > Thanks & regards, > = > Jaekwon OH > = > ---------------------------------------------------------------------= --- > = > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > = > = > ------------------------------------------------------------------------ > = > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 7 06:21:51 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A96BF3A6BCF; Thu, 7 Aug 2008 06:21:51 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5971B3A6870 for ; Thu, 7 Aug 2008 06:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 yb9C2A3MXg3R for ; Thu, 7 Aug 2008 06:21:42 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 7D23E3A6830 for ; Thu, 7 Aug 2008 06:21:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,320,1215403200"; d="scan'208,217";a="138612328" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 07 Aug 2008 09:22:07 -0400 X-IronPort-AV: E=Sophos;i="4.31,320,1215403200"; d="scan'208,217";a="245988491" Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 07 Aug 2008 09:22:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 14:22:05 +0100 Message-ID: <4C607BEA097DF048BEA625B974A36618730EE1@306900ANEX2.global.avaya.com> In-Reply-To: <012301c8f84c$eeeb9a80$cf1a590a@JKOH> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] How to show presentity's relative service preference Thread-Index: Acj4TSUcDhqK8xpdTE6g/mW4MgnDfAAPPR6Q References: <005001c8f69b$54282520$cf1a590a@JKOH> <4C607BEA097DF048BEA625B974A36618730B56@306900ANEX2.global.avaya.com> <012301c8f84c$eeeb9a80$cf1a590a@JKOH> From: "Smyth, Colm (Colm)" To: "JaekwonOH" , "Simple WG" Subject: Re: [Simple] How to show presentity's relative service preference X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1412238791==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1412238791== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F890.9666E9D0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F890.9666E9D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable You're describing a content-based dispatch scenario; as you note, a content-oriented application isn't identifiable or addressable using a URI. =20 The tuple class-id may help with identification, however there is little guidance in the existing RFCs on what makes a good class-id. For content-dispatch over a generic protocol (e.g. SIP or even HTTP), the actual MIME-type would be useful. For other uses, it would be possible to use a similar constructive approach to create an identifier that identifies application in arbitrary levels of detail (e.g. service/protocol/vendor+version). =20 All the best, Colm Smyth AVAYA | smythc@avaya.com =20 ________________________________ From: JaekwonOH [mailto:jaekwon.oh@samsung.com]=20 Sent: 07 August 2008 06:18 To: Simple WG; Smyth, Colm (Colm) Subject: Re: [Simple] How to show presentity's relative service preference Hi, =20 Thanks for response. Even when the device contact URI registered for an AOR is used for tuple's contact address, the uniqueness of the contact address for a tupe seems not guaranteed. For example, a device may run multiple SIP applications, then tuples for each of those would contain the same URI. This aspect has already been clarified in RFC 4479 (see the following excerption). Therefore, IMHO, the uniquness of contact address for each tuple seem not guaranteed, so the use of 'priority' attribute of in is not enogh to show the presenity's relative service preference. =20 >From RFC 4479 section 3.3.2 reach information, =20 Even for services reachable over a communications network, the URI alone may not be sufficient. For example, two applications may be running within a cellular telephone, both of which are reachable through the user's SIP Address of Record. However, one application is launched when the INVITE request contains a body of a particular type, and the other is launched for other body types. As another example, a service may provide complex application logic that operates correctly only when contacted from matching application software. In such a case, even though the communications between instances utilizes a standard protocol (such as SIP), the user experience will not be correct unless the applications are matched. When the URI is not sufficient, additional attributes of the service can be present that define the instructions on how the service is to be reached. These attributes must be understood for the service to be utilized. If a watcher receives a presence document containing reach information it does not understand, it should discard the service information. =20 =20 Thanks & regards, Jaekwon OH ----- Original Message -----=20 From: Smyth, Colm (Colm) =20 To: Simple WG =20 Sent: Wednesday, August 06, 2008 1:23 AM Subject: Re: [Simple] How to show presentity's relative service preference I suggest that if there are multiple contact addresses for a single AOR, the contact element of each related tuple in PIDF should reflect a unique contact address for this AOR, not the ambiguous AOR itself. =20 A unique address is useful, not just as an identifier for the tuple's source, but to reach the address; then, the priority attribute has a meaningful scope. =20 Colm Smyth Lead/Architect - Intelligent Presence Server (IPS) | Unified Communications AVAYA | smythc@avaya.com | +353 1 656 7843 (x37843) =20 ________________________________ From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of JaekwonOH Sent: 05 August 2008 02:34 To: Simple WG Subject: [Simple] How to show presentity's relative service preference =09 =09 Hi all, =20 I'm wondering how a presentity can show his perferred services in presence. A possibility seems to use the 'priority' attribute of element for this purpose. However, RFC 3863 defines that the 'priority' attribute shows the presentity's different preference over *contact address*, so it is not clear whether this is good enough to show the presentity's relative service preference.=20 For example, when there are multiple SIP services that share the presentity's AOR as contact address, then how the different 'priority' attribute value for the same contact address should be interpreted? IMHO, this happens because a service cannot be represented only with the contact information. Rather, as noted in RFC 4476, a service is identified by the "reach information", which is a set of presence information to reach the service including the contact address. If this is the case, what should we do? =09 =09 Thanks & regards, =20 Jaekwon OH =09 ________________________________ =09 _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple =09 ------_=_NextPart_001_01C8F890.9666E9D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
You're describing a content-based dispatch = scenario; as=20 you note, a content-oriented application isn't identifiable or = addressable using=20 a URI.
 
The tuple class-id may help with = identification,=20 however there is little guidance in the existing RFCs on what makes a = good=20 class-id. For content-dispatch over a generic protocol = (e.g. SIP=20 or even HTTP), the actual MIME-type would be useful. For other uses, it = would be=20 possible to use a similar constructive approach to create an identifier = that=20 identifies application in arbitrary levels of detail (e.g.=20 service/protocol/vendor+version).
 
All=20 the best,
Colm Smyth
AVAYA | smythc@avaya.com
 

From: JaekwonOH = [mailto:jaekwon.oh@samsung.com]=20
Sent: 07 August 2008 06:18
To: Simple WG; Smyth, = Colm=20 (Colm)
Subject: Re: [Simple] How to show presentity's relative = service=20 preference

Hi,
 
Thanks for response.
Even when the device contact URI = registered for an=20 AOR is used for tuple's contact address, the uniqueness of the = contact=20 address for a tupe seems not guaranteed. For example, a device may=20 run multiple SIP applications, then tuples for each of those would = contain=20 the same URI.
This aspect has already been clarified in RFC 4479 = (see the=20 following excerption).
Therefore, IMHO, the uniquness of contact address = for each=20 tuple seem not guaranteed, so the use of 'priority' attribute of=20 <contact> in <tuple> is not enogh to show the presenity's = relative=20 service preference.
 
From RFC 4479 section 3.3.2 reach=20 information,
 
Even for services reachable over a communications = network, the=20 URI
alone may not be sufficient. For example, two applications may=20 be
running within a cellular telephone, both of which are=20 reachable
through the user’s SIP Address of Record. However, = one=20 application
is launched when the INVITE request contains a body of a=20 particular
type, and the other is launched for other body types. As=20 another
example, a service may provide complex application logic=20 that
operates correctly only when contacted from matching=20 application
software. In such a case, even though the communications=20 between
instances utilizes a standard protocol (such as SIP), the=20 user
experience will not be correct unless the applications are=20 matched.
When the URI is not sufficient, additional attributes of the = service
can be present that define the instructions on how the = service is=20 to
be reached. These attributes must be understood for the service = to
be=20 utilized. If a watcher receives a presence document containing
reach=20 information it does not understand, it should discard the
service=20 information.
 
 
Thanks & regards,
Jaekwon OH
----- Original Message -----
From: Smyth, Colm = (Colm)=20
Sent: Wednesday, = August 06, 2008 1:23=20 AM
Subject: Re: = [Simple] How to show=20 presentity's relative service preference

I suggest that if there are multiple = contact=20 addresses for a single AOR, the contact element of each related tuple = in PIDF=20 should reflect a unique contact address for this AOR, not the = ambiguous AOR=20 itself.
 
A unique address is useful, not just as an = identifier=20 for the tuple's source, but to reach the address; then, the priority = attribute=20 has a meaningful scope.
 
Colm Smyth
Lead/Architect=20 - Intelligent Presence Server (IPS) | Unified=20 Communications
AVAYA | smythc@avaya.com | +353=20 1 656 7843 = (x37843)
 

From: simple-bounces@ietf.org=20 [mailto:simple-bounces@ietf.org] On Behalf Of = JaekwonOH
Sent:=20 05 August 2008 02:34
To: Simple WG
Subject: = [Simple] How=20 to show presentity's relative service preference

Hi all,
 
I'm wondering how a = presentity can=20 show his perferred services in presence.
A possibility seems to use = the=20 'priority' attribute of <contact> element for this = purpose.
However,=20 RFC 3863 defines that the 'priority' attribute shows the presentity's=20 different preference over *contact address*, so it is not clear = whether this=20 is good enough to show the presentity's relative service preference. =
For=20 example, when there are multiple SIP services that share the = presentity's AOR=20 as contact address, then how the different 'priority' attribute value = for the=20 same contact address should be interpreted?
IMHO, this happens = because a=20 service cannot be represented only with the contact information. = Rather, as=20 noted in RFC 4476, a service is identified by the "reach information", = which=20 is a set of presence information to reach the service including the = contact=20 address.
If this is the case, what = should we=20 do?
Thanks & = regards,
 
Jaekwon OH

_______________________________________________
Simple = mailing=20 = list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple ------_=_NextPart_001_01C8F890.9666E9D0-- --===============1412238791== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============1412238791==-- From simple-bounces@ietf.org Thu Aug 7 23:38:21 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4BB3A6C9B; Thu, 7 Aug 2008 23:38:21 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFBB73A6C9D for ; Thu, 7 Aug 2008 23:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.562 X-Spam-Level: ** X-Spam-Status: No, score=2.562 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_BASE64_TEXT=1.753, RELAY_IS_203=0.994] 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 djxiXFRH86MX for ; Thu, 7 Aug 2008 23:38:18 -0700 (PDT) Received: from mailout5.samsung.com (mailout5.samsung.com [203.254.224.35]) by core3.amsl.com (Postfix) with ESMTP id 7C3953A6C9B for ; Thu, 7 Aug 2008 23:38:18 -0700 (PDT) Received: from epmmp1 (mailout5.samsung.com [203.254.224.35]) by mailout5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K59000SSRRN8I@mailout5.samsung.com> for simple@ietf.org; Fri, 08 Aug 2008 15:38:11 +0900 (KST) Received: from JKOH ([10.89.26.207]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0K5900692RRNJA@mmp1.samsung.com> for simple@ietf.org; Fri, 08 Aug 2008 15:38:11 +0900 (KST) Date: Fri, 08 Aug 2008 15:38:00 +0900 From: JaekwonOH To: Paul Kyzivat Message-id: <00e201c8f921$4d33b350$cf1a590a@JKOH> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <005001c8f69b$54282520$cf1a590a@JKOH> <4C607BEA097DF048BEA625B974A36618730B56@306900ANEX2.global.avaya.com> <012301c8f84c$eeeb9a80$cf1a590a@JKOH> <489AE135.4050000@cisco.com> Cc: Simple WG Subject: Re: [Simple] How to show presentity's relative service preference X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Thanks for comment. > Only if it wants them to. It certainly may use a separate contact uri = > for each application. (They probably have the same address and are = > distinguished by the user part, or port.) Its the responsibility of the = > application to put in enough uniqueness to get proper results. I agree that if all each application can have unique contact address then t= here's no problem. However, as I understand relevant RFCs incl. RFC4479, this seems not always= the case. = So, when the contact address is not unique over different applications, it = is questionable whether the priority attribute can be still meaningful to s= how presentity's relative service preference... Thanks & regards, Jaekwon OH ----- Original Message ----- = From: "Paul Kyzivat" To: "JaekwonOH" Cc: "Simple WG" ; "Smyth, Colm (Colm)" Sent: Thursday, August 07, 2008 8:49 PM Subject: Re: [Simple] How to show presentity's relative service preference > = > = > JaekwonOH wrote: >> Hi, >> = >> Thanks for response. >> Even when the device contact URI registered for an AOR is used for = >> tuple's contact address, the uniqueness of the contact address for a = >> tupe seems not guaranteed. For example, a device may run multiple SIP = >> applications, then tuples for each of those would contain the same URI. > = > Only if it wants them to. It certainly may use a separate contact uri = > for each application. (They probably have the same address and are = > distinguished by the user part, or port.) Its the responsibility of the = > application to put in enough uniqueness to get proper results. > = > Paul > = >> This aspect has already been clarified in RFC 4479 (see the following = >> excerption). >> Therefore, IMHO, the uniquness of contact address for each tuple seem = >> not guaranteed, so the use of 'priority' attribute of in = >> is not enogh to show the presenity's relative service preference. >> = >> From RFC 4479 section 3.3.2 reach information, >> = >> Even for services reachable over a communications network, the URI >> alone may not be sufficient. For example, two applications may be >> running within a cellular telephone, both of which are reachable >> through the user=92s SIP Address of Record. However, one application >> is launched when the INVITE request contains a body of a particular >> type, and the other is launched for other body types. As another >> example, a service may provide complex application logic that >> operates correctly only when contacted from matching application >> software. In such a case, even though the communications between >> instances utilizes a standard protocol (such as SIP), the user >> experience will not be correct unless the applications are matched. >> When the URI is not sufficient, additional attributes of the service >> can be present that define the instructions on how the service is to >> be reached. These attributes must be understood for the service to >> be utilized. If a watcher receives a presence document containing >> reach information it does not understand, it should discard the >> service information. >> = >> = >> Thanks & regards, >> Jaekwon OH >> ----- Original Message ----- >> = >> *From:* Smyth, Colm (Colm) >> *To:* Simple WG >> *Sent:* Wednesday, August 06, 2008 1:23 AM >> *Subject:* Re: [Simple] How to show presentity's relative service >> preference >> = >> I suggest that if there are multiple contact addresses for a single >> AOR, the contact element of each related tuple in PIDF should >> reflect a unique contact address for this AOR, not the ambiguous AOR >> itself. >> = >> A unique address is useful, not just as an identifier for the >> tuple's source, but to reach the address; then, the priority >> attribute has a meaningful scope. >> = >> Colm Smyth >> Lead/Architect - Intelligent Presence Server (IPS) | Unified >> Communications >> *AVAYA* | smythc@avaya.com | +353 1 656 >> 7843 (x37843) >> = >> = >> --------------------------------------------------------------------= ---- >> *From:* simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] *On >> Behalf Of *JaekwonOH >> *Sent:* 05 August 2008 02:34 >> *To:* Simple WG >> *Subject:* [Simple] How to show presentity's relative service prefer= ence >> = >> Hi all, >> = >> I'm wondering how a presentity can show his perferred services in >> presence. >> A possibility seems to use the 'priority' attribute of >> element for this purpose. >> However, RFC 3863 defines that the 'priority' attribute shows the >> presentity's different preference over *contact address*, so it is >> not clear whether this is good enough to show the presentity's >> relative service preference. >> For example, when there are multiple SIP services that share the >> presentity's AOR as contact address, then how the different >> 'priority' attribute value for the same contact address should be >> interpreted? >> IMHO, this happens because a service cannot be represented only with >> the contact information. Rather, as noted in RFC 4476, a service is >> identified by the "reach information", which is a set of presence >> information to reach the service including the contact address. >> If this is the case, what should we do? >> Thanks & regards, >> = >> Jaekwon OH >> = >> --------------------------------------------------------------------= ---- >> = >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> = >> = >> ------------------------------------------------------------------------ >> = >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 7 23:39:33 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B303A6CA3; Thu, 7 Aug 2008 23:39:33 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9C743A6C98 for ; Thu, 7 Aug 2008 23:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.645 X-Spam-Level: X-Spam-Status: No, score=-0.645 tagged_above=-999 required=5 tests=[AWL=3.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] 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 OMscCMQHGv9e for ; Thu, 7 Aug 2008 23:39:30 -0700 (PDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by core3.amsl.com (Postfix) with ESMTP id 35B613A6CA3 for ; Thu, 7 Aug 2008 23:39:30 -0700 (PDT) Received: from epmmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K59002NHRTOON@mailout2.samsung.com> for simple@ietf.org; Fri, 08 Aug 2008 15:39:24 +0900 (KST) Received: from JKOH ([10.89.26.207]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0K590071GRTN8H@mmp1.samsung.com> for simple@ietf.org; Fri, 08 Aug 2008 15:39:24 +0900 (KST) Date: Fri, 08 Aug 2008 15:39:12 +0900 From: JaekwonOH To: Simple WG , "Smyth, Colm (Colm)" Message-id: <00e601c8f921$7848e7e0$cf1a590a@JKOH> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <005001c8f69b$54282520$cf1a590a@JKOH> <4C607BEA097DF048BEA625B974A36618730B56@306900ANEX2.global.avaya.com> <012301c8f84c$eeeb9a80$cf1a590a@JKOH> <4C607BEA097DF048BEA625B974A36618730EE1@306900ANEX2.global.avaya.com> Subject: Re: [Simple] How to show presentity's relative service preference X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1719202211==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1719202211== Content-type: multipart/alternative; boundary="Boundary_(ID_lla9QHvRdKCbF8/fJCVL6Q)" This is a multi-part message in MIME format. --Boundary_(ID_lla9QHvRdKCbF8/fJCVL6Q) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT It seems we now share the understanding that a service may not be uniquely identifiable with the contact URI only. Then, the question is whether the priority attribute is still meaningful to show presentity's relative service preference.. Thanks & regards, Jaekwon OH ----- Original Message ----- From: Smyth, Colm (Colm) To: JaekwonOH ; Simple WG Sent: Thursday, August 07, 2008 10:22 PM Subject: RE: [Simple] How to show presentity's relative service preference You're describing a content-based dispatch scenario; as you note, a content-oriented application isn't identifiable or addressable using a URI. The tuple class-id may help with identification, however there is little guidance in the existing RFCs on what makes a good class-id. For content-dispatch over a generic protocol (e.g. SIP or even HTTP), the actual MIME-type would be useful. For other uses, it would be possible to use a similar constructive approach to create an identifier that identifies application in arbitrary levels of detail (e.g. service/protocol/vendor+version). All the best, Colm Smyth AVAYA | smythc@avaya.com ------------------------------------------------------------------------------ From: JaekwonOH [mailto:jaekwon.oh@samsung.com] Sent: 07 August 2008 06:18 To: Simple WG; Smyth, Colm (Colm) Subject: Re: [Simple] How to show presentity's relative service preference Hi, Thanks for response. Even when the device contact URI registered for an AOR is used for tuple's contact address, the uniqueness of the contact address for a tupe seems not guaranteed. For example, a device may run multiple SIP applications, then tuples for each of those would contain the same URI. This aspect has already been clarified in RFC 4479 (see the following excerption). Therefore, IMHO, the uniquness of contact address for each tuple seem not guaranteed, so the use of 'priority' attribute of in is not enogh to show the presenity's relative service preference. From RFC 4479 section 3.3.2 reach information, Even for services reachable over a communications network, the URI alone may not be sufficient. For example, two applications may be running within a cellular telephone, both of which are reachable through the user's SIP Address of Record. However, one application is launched when the INVITE request contains a body of a particular type, and the other is launched for other body types. As another example, a service may provide complex application logic that operates correctly only when contacted from matching application software. In such a case, even though the communications between instances utilizes a standard protocol (such as SIP), the user experience will not be correct unless the applications are matched. When the URI is not sufficient, additional attributes of the service can be present that define the instructions on how the service is to be reached. These attributes must be understood for the service to be utilized. If a watcher receives a presence document containing reach information it does not understand, it should discard the service information. Thanks & regards, Jaekwon OH ----- Original Message ----- From: Smyth, Colm (Colm) To: Simple WG Sent: Wednesday, August 06, 2008 1:23 AM Subject: Re: [Simple] How to show presentity's relative service preference I suggest that if there are multiple contact addresses for a single AOR, the contact element of each related tuple in PIDF should reflect a unique contact address for this AOR, not the ambiguous AOR itself. A unique address is useful, not just as an identifier for the tuple's source, but to reach the address; then, the priority attribute has a meaningful scope. Colm Smyth Lead/Architect - Intelligent Presence Server (IPS) | Unified Communications AVAYA | smythc@avaya.com | +353 1 656 7843 (x37843) ---------------------------------------------------------------------------- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of JaekwonOH Sent: 05 August 2008 02:34 To: Simple WG Subject: [Simple] How to show presentity's relative service preference Hi all, I'm wondering how a presentity can show his perferred services in presence. A possibility seems to use the 'priority' attribute of element for this purpose. However, RFC 3863 defines that the 'priority' attribute shows the presentity's different preference over *contact address*, so it is not clear whether this is good enough to show the presentity's relative service preference. For example, when there are multiple SIP services that share the presentity's AOR as contact address, then how the different 'priority' attribute value for the same contact address should be interpreted? IMHO, this happens because a service cannot be represented only with the contact information. Rather, as noted in RFC 4476, a service is identified by the "reach information", which is a set of presence information to reach the service including the contact address. If this is the case, what should we do? Thanks & regards, Jaekwon OH ---------------------------------------------------------------------------- _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --Boundary_(ID_lla9QHvRdKCbF8/fJCVL6Q) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuNjAwMC4xNjY3NCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkl0IDwvRk9OVD48 Rk9OVCBzaXplPTI+c2VlbXMgd2Ugbm93Jm5ic3A7c2hhcmUgdGhlIA0KdW5kZXJzdGFuZGluZyB0 aGF0IGEgc2VydmljZSBtYXkgbm90IGJlIHVuaXF1ZWx5IGlkZW50aWZpYWJsZSB3aXRoIHRoZSBj b250YWN0IA0KVVJJIG9ubHkuIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRoZW4s Jm5ic3A7dGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhlIHByaW9yaXR5IGF0dHJpYnV0ZSBpcyAN CnN0aWxsIG1lYW5pbmdmdWwgdG8gc2hvdyBwcmVzZW50aXR5J3MgcmVsYXRpdmUgc2VydmljZSBw cmVmZXJlbmNlLi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5UaGFua3MgJmFtcDsgcmVnYXJkcyw8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5KYWVrd29uIE9IPEJSPjwvRk9OVD48L0RJVj4NCjxCTE9D S1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6 IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBN QVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgJiM0NDQwNDsmIzQ3 NTQ4OyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJViANCiAgc3R5 bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDEwcHQgJiM0NDQwNDsmIzQ3NTQ4OzsgZm9u dC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiA8QSANCiAgdGl0bGU9c215dGhjQGF2YXlhLmNv bSBocmVmPSJtYWlsdG86c215dGhjQGF2YXlhLmNvbSI+U215dGgsIENvbG0gKENvbG0pPC9BPiAN CiAgPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgJiM0NDQwNDsmIzQ3NTQ4OyI+PEI+ VG86PC9CPiA8QSB0aXRsZT1qYWVrd29uLm9oQHNhbXN1bmcuY29tIA0KICBocmVmPSJtYWlsdG86 amFla3dvbi5vaEBzYW1zdW5nLmNvbSI+SmFla3dvbk9IPC9BPiA7IDxBIHRpdGxlPXNpbXBsZUBp ZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRvOnNpbXBsZUBpZXRmLm9yZyI+U2ltcGxlIFdHPC9BPiA8 L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCAmIzQ0NDA0OyYjNDc1NDg7Ij48Qj5TZW50 OjwvQj4gVGh1cnNkYXksIEF1Z3VzdCAwNywgMjAwOCAxMDoyMiANCiAgUE08L0RJVj4NCiAgPERJ ViBzdHlsZT0iRk9OVDogMTBwdCAmIzQ0NDA0OyYjNDc1NDg7Ij48Qj5TdWJqZWN0OjwvQj4gUkU6 IFtTaW1wbGVdIEhvdyB0byBzaG93IA0KICBwcmVzZW50aXR5J3MgcmVsYXRpdmUgc2VydmljZSBw cmVmZXJlbmNlPC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249 bGVmdD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFz cz04ODkzOTM1MTItMDcwODIwMDg+WW91J3JlIGRlc2NyaWJpbmcgYSBjb250ZW50LWJhc2VkIGRp c3BhdGNoIHNjZW5hcmlvOyANCiAgYXMgeW91IG5vdGUsIGEgY29udGVudC1vcmllbnRlZCBhcHBs aWNhdGlvbiBpc24ndCBpZGVudGlmaWFibGUgb3IgYWRkcmVzc2FibGUgDQogIHVzaW5nIGEgVVJJ LjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTg4OTM5MzUxMi0w NzA4MjAwOD48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249 bGVmdD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFz cz04ODkzOTM1MTItMDcwODIwMDg+VGhlIHR1cGxlIGNsYXNzLWlkIG1heSBoZWxwIHdpdGggaWRl bnRpZmljYXRpb24sIA0KICBob3dldmVyIHRoZXJlIGlzIGxpdHRsZSBndWlkYW5jZSBpbiB0aGUg ZXhpc3RpbmcgUkZDcyBvbiB3aGF0IG1ha2VzIGEgZ29vZCANCiAgY2xhc3MtaWQuIDwvU1BBTj48 L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgY2xh c3M9ODg5MzkzNTEyLTA3MDgyMDA4PkZvciBjb250ZW50LWRpc3BhdGNoIG92ZXIgYSBnZW5lcmlj IHByb3RvY29sIChlLmcuIA0KICBTSVAgb3IgZXZlbiBIVFRQKSwgdGhlIGFjdHVhbCBNSU1FLXR5 cGUgd291bGQgYmUgdXNlZnVsLiBGb3Igb3RoZXIgdXNlcywgaXQgDQogIHdvdWxkIGJlIHBvc3Np YmxlIHRvIHVzZSBhIHNpbWlsYXIgY29uc3RydWN0aXZlIGFwcHJvYWNoIHRvIGNyZWF0ZSBhbiAN CiAgaWRlbnRpZmllciB0aGF0IGlkZW50aWZpZXMgYXBwbGljYXRpb24gaW4gYXJiaXRyYXJ5IGxl dmVscyBvZiBkZXRhaWwgKGUuZy4gDQogIHNlcnZpY2UvcHJvdG9jb2wvdmVuZG9yK3ZlcnNpb24p LjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAw MGZmIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9ODg5Mzkz NTEyLTA3MDgyMDA4PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+QWxsIA0K ICB0aGUgYmVzdCw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWIGFsaWduPWxlZnQ+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBncmF5OyBGT05ULUZBTUlMWTogJ0Nl bnR1cnkgR290aGljJywnc2Fucy1zZXJpZiciPjxGT05UIA0KICBmYWNlPUFyaWFsPkNvbG0gU215 dGg8L0ZPTlQ+PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlM WTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJyI+PEJSPjwvU1BBTj48Rk9OVCANCiAgc2l6ZT0x PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgDQogIGNvbG9yPSNmZjAwMDA+PFNQQU4+PFNUUk9ORz5B VkFZQTwvU1RST05HPiZuYnNwO3w8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDcu NXB0OyBDT0xPUjogZ3JlZW47IEZPTlQtRkFNSUxZOiAnQ2VudHVyeSBHb3RoaWMnLCdzYW5zLXNl cmlmJyI+PEZPTlQgDQogIGZhY2U9QXJpYWwgc2l6ZT0xPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9G T05UPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiA3LjVwdDsgQ09MT1I6IGdyZWVuOyBGT05U LUZBTUlMWTogJ0NlbnR1cnkgR290aGljJywnc2Fucy1zZXJpZiciPjxBIA0KICBocmVmPSJtYWls dG86c215dGhjQGF2YXlhLmNvbSI+c215dGhjQGF2YXlhLmNvbTwvQT48L1NQQU4+PC9GT05UPjwv Rk9OVD48L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj48QlI+DQogIDxESVYgY2xhc3M9T3V0bG9v a01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9bHRyIGFsaWduPWxlZnQ+DQogIDxIUiB0YWJJ bmRleD0tMT4NCiAgPEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0yPjxCPkZyb206PC9CPiBKYWVrd29u T0ggDQogIFttYWlsdG86amFla3dvbi5vaEBzYW1zdW5nLmNvbV0gPEJSPjxCPlNlbnQ6PC9CPiAw NyBBdWd1c3QgMjAwOCANCiAgMDY6MTg8QlI+PEI+VG86PC9CPiBTaW1wbGUgV0c7IFNteXRoLCBD b2xtIChDb2xtKTxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IA0KICBbU2ltcGxlXSBIb3cgdG8gc2hv dyBwcmVzZW50aXR5J3MgcmVsYXRpdmUgc2VydmljZSANCiAgcHJlZmVyZW5jZTxCUj48L0ZPTlQ+ PEJSPjwvRElWPg0KICA8RElWPjwvRElWPg0KICA8RElWPjxGT05UIHNpemU9Mj5IaSw8L0ZPTlQ+ PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48 Rk9OVCBzaXplPTI+VGhhbmtzIGZvciByZXNwb25zZS48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZP TlQgc2l6ZT0yPkV2ZW4mbmJzcDt3aGVuJm5ic3A7dGhlIGRldmljZSBjb250YWN0IFVSSSByZWdp c3RlcmVkIGZvciBhbiANCiAgQU9SJm5ic3A7aXMgdXNlZCBmb3IgdHVwbGUncyBjb250YWN0IGFk ZHJlc3MsIHRoZSB1bmlxdWVuZXNzIG9mIHRoZSBjb250YWN0IA0KICBhZGRyZXNzIGZvciBhIHR1 cGUgc2VlbXMgbm90IGd1YXJhbnRlZWQuIEZvciBleGFtcGxlLCZuYnNwO2EgZGV2aWNlIG1heSAN CiAgcnVuJm5ic3A7bXVsdGlwbGUgU0lQIGFwcGxpY2F0aW9ucywgdGhlbiB0dXBsZXMgZm9yIGVh Y2ggb2YgdGhvc2Ugd291bGQgDQogIGNvbnRhaW4gdGhlIHNhbWUgVVJJLjwvRk9OVD48L0RJVj4N CiAgPERJVj48Rk9OVCBzaXplPTI+VGhpcyBhc3BlY3QgaGFzIGFscmVhZHkgYmVlbiBjbGFyaWZp ZWQgaW4gUkZDIDQ0NzkgKHNlZSB0aGUgDQogIGZvbGxvd2luZyBleGNlcnB0aW9uKS48L0ZPTlQ+ PC9ESVY+DQogIDxESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yPlRoZXJlZm9yZSwgSU1ITywgdGhl IHVuaXF1bmVzcyBvZiBjb250YWN0IGFkZHJlc3MgZm9yIGVhY2ggDQogIHR1cGxlIHNlZW0gbm90 IGd1YXJhbnRlZWQsIHNvJm5ic3A7dGhlIHVzZSBvZiAncHJpb3JpdHknIGF0dHJpYnV0ZSBvZiAN CiAgJmx0O2NvbnRhY3QmZ3Q7IGluICZsdDt0dXBsZSZndDsgaXMgbm90IGVub2doIHRvIHNob3cg dGhlIHByZXNlbml0eSdzIHJlbGF0aXZlIA0KICBzZXJ2aWNlIHByZWZlcmVuY2UuPC9GT05UPjwv RElWPjwvRElWPg0KICA8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxE SVY+PEZPTlQgc2l6ZT0yPkZyb20gUkZDIDQ0NzkmbmJzcDtzZWN0aW9uIDMuMy4yIHJlYWNoIA0K ICBpbmZvcm1hdGlvbiw8L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTI+RXZlbiBmb3Igc2VydmljZXMgcmVhY2hh YmxlIG92ZXIgYSBjb21tdW5pY2F0aW9ucyBuZXR3b3JrLCANCiAgdGhlIFVSSTxCUj5hbG9uZSBt YXkgbm90IGJlIHN1ZmZpY2llbnQuIEZvciBleGFtcGxlLCB0d28gYXBwbGljYXRpb25zIG1heSAN CiAgYmU8QlI+cnVubmluZyB3aXRoaW4gYSBjZWxsdWxhciB0ZWxlcGhvbmUsIGJvdGggb2Ygd2hp Y2ggYXJlIA0KICByZWFjaGFibGU8QlI+dGhyb3VnaCB0aGUgdXNlcpJzIFNJUCBBZGRyZXNzIG9m IFJlY29yZC4gSG93ZXZlciwgb25lIA0KICBhcHBsaWNhdGlvbjxCUj5pcyBsYXVuY2hlZCB3aGVu IHRoZSBJTlZJVEUgcmVxdWVzdCBjb250YWlucyBhIGJvZHkgb2YgYSANCiAgcGFydGljdWxhcjxC Uj50eXBlLCBhbmQgdGhlIG90aGVyIGlzIGxhdW5jaGVkIGZvciBvdGhlciBib2R5IHR5cGVzLiBB cyANCiAgYW5vdGhlcjxCUj5leGFtcGxlLCBhIHNlcnZpY2UgbWF5IHByb3ZpZGUgY29tcGxleCBh cHBsaWNhdGlvbiBsb2dpYyANCiAgdGhhdDxCUj5vcGVyYXRlcyBjb3JyZWN0bHkgb25seSB3aGVu IGNvbnRhY3RlZCBmcm9tIG1hdGNoaW5nIA0KICBhcHBsaWNhdGlvbjxCUj5zb2Z0d2FyZS4gSW4g c3VjaCBhIGNhc2UsIGV2ZW4gdGhvdWdoIHRoZSBjb21tdW5pY2F0aW9ucyANCiAgYmV0d2VlbjxC Uj5pbnN0YW5jZXMgdXRpbGl6ZXMgYSBzdGFuZGFyZCBwcm90b2NvbCAoc3VjaCBhcyBTSVApLCB0 aGUgDQogIHVzZXI8QlI+ZXhwZXJpZW5jZSB3aWxsIG5vdCBiZSBjb3JyZWN0IHVubGVzcyB0aGUg YXBwbGljYXRpb25zIGFyZSANCiAgbWF0Y2hlZC48QlI+V2hlbiB0aGUgVVJJIGlzIG5vdCBzdWZm aWNpZW50LCBhZGRpdGlvbmFsIGF0dHJpYnV0ZXMgb2YgdGhlIA0KICBzZXJ2aWNlPEJSPmNhbiBi ZSBwcmVzZW50IHRoYXQgZGVmaW5lIHRoZSBpbnN0cnVjdGlvbnMgb24gaG93IHRoZSBzZXJ2aWNl IGlzIA0KICB0bzxCUj5iZSByZWFjaGVkLiBUaGVzZSBhdHRyaWJ1dGVzIG11c3QgYmUgdW5kZXJz dG9vZCBmb3IgdGhlIHNlcnZpY2UgdG88QlI+YmUgDQogIHV0aWxpemVkLiBJZiBhIHdhdGNoZXIg cmVjZWl2ZXMgYSBwcmVzZW5jZSBkb2N1bWVudCBjb250YWluaW5nPEJSPnJlYWNoIA0KICBpbmZv cm1hdGlvbiBpdCBkb2VzIG5vdCB1bmRlcnN0YW5kLCBpdCBzaG91bGQgZGlzY2FyZCB0aGU8QlI+ c2VydmljZSANCiAgaW5mb3JtYXRpb24uPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIHNpemU9 Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTI+VGhhbmtzICZhbXA7IHJlZ2FyZHMsPC9GT05UPjwv RElWPg0KICA8RElWPjxGT05UIHNpemU9Mj5KYWVrd29uIE9IPEJSPjwvRk9OVD48L0RJVj4NCiAg PERJVj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8QkxPQ0tRVU9URSAN CiAgc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1M RUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAw cHgiPg0KICAgIDxESVYgDQogICAgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDEw cHQgJiM0NDQwNDsmIzQ3NTQ4OzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAg ICA8QSB0aXRsZT1zbXl0aGNAYXZheWEuY29tIGhyZWY9Im1haWx0bzpzbXl0aGNAYXZheWEuY29t Ij5TbXl0aCwgQ29sbSANCiAgICAoQ29sbSk8L0E+IDwvRElWPg0KICAgIDxESVYgc3R5bGU9IkZP TlQ6IDEwcHQgJiM0NDQwNDsmIzQ3NTQ4OyI+PEI+VG86PC9CPiA8QSB0aXRsZT1zaW1wbGVAaWV0 Zi5vcmcgDQogICAgaHJlZj0ibWFpbHRvOnNpbXBsZUBpZXRmLm9yZyI+U2ltcGxlIFdHPC9BPiA8 L0RJVj4NCiAgICA8RElWIHN0eWxlPSJGT05UOiAxMHB0ICYjNDQ0MDQ7JiM0NzU0ODsiPjxCPlNl bnQ6PC9CPiBXZWRuZXNkYXksIEF1Z3VzdCAwNiwgMjAwOCAxOjIzIA0KICAgIEFNPC9ESVY+DQog ICAgPERJViBzdHlsZT0iRk9OVDogMTBwdCAmIzQ0NDA0OyYjNDc1NDg7Ij48Qj5TdWJqZWN0Ojwv Qj4gUmU6IFtTaW1wbGVdIEhvdyB0byBzaG93IA0KICAgIHByZXNlbnRpdHkncyByZWxhdGl2ZSBz ZXJ2aWNlIHByZWZlcmVuY2U8L0RJVj4NCiAgICA8RElWPjxCUj48L0RJVj4NCiAgICA8RElWIGRp cj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxT UEFOIA0KICAgIGNsYXNzPTI3NjM0MzExNS0wNTA4MjAwOD5JIHN1Z2dlc3QgdGhhdCBpZiB0aGVy ZSBhcmUgbXVsdGlwbGUgY29udGFjdCANCiAgICBhZGRyZXNzZXMgZm9yIGEgc2luZ2xlIEFPUiwg dGhlIGNvbnRhY3QgZWxlbWVudCBvZiBlYWNoIHJlbGF0ZWQgdHVwbGUgaW4gDQogICAgUElERiBz aG91bGQgcmVmbGVjdCBhIHVuaXF1ZSBjb250YWN0IGFkZHJlc3MgZm9yIHRoaXMgQU9SLCBub3Qg dGhlIGFtYmlndW91cyANCiAgICBBT1IgaXRzZWxmLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAg PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNp emU9Mj48U1BBTiANCiAgICBjbGFzcz0yNzYzNDMxMTUtMDUwODIwMDg+PC9TUEFOPjwvRk9OVD4m bmJzcDs8L0RJVj4NCiAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFs IGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgIGNsYXNzPTI3NjM0MzExNS0wNTA4MjAw OD5BIHVuaXF1ZSBhZGRyZXNzIGlzIHVzZWZ1bCwgbm90IGp1c3QgYXMgYW4gDQogICAgaWRlbnRp ZmllciBmb3IgdGhlIHR1cGxlJ3Mgc291cmNlLCBidXQgdG8gcmVhY2ggdGhlIGFkZHJlc3M7IHRo ZW4sIHRoZSANCiAgICBwcmlvcml0eSBhdHRyaWJ1dGUgaGFzIGEgbWVhbmluZ2Z1bCBzY29wZS48 L1NQQU4+PC9GT05UPjwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAw MGZmIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgPERJViBhbGlnbj1sZWZ0PjxTUEFO IA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBncmF5OyBGT05ULUZBTUlMWTog J0NlbnR1cnkgR290aGljJywnc2Fucy1zZXJpZiciPjxGT05UIA0KICAgIGZhY2U9QXJpYWw+Q29s bSBTbXl0aDwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgPERJViBhbGlnbj1sZWZ0PjxTUEFOIA0K ICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBncmF5OyBGT05ULUZBTUlMWTogJ0Nl bnR1cnkgR290aGljJywnc2Fucy1zZXJpZiciPjwvU1BBTj48Rk9OVCANCiAgICBzaXplPTE+PEZP TlQgZmFjZT1BcmlhbD48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiA3LjVwdDsgQ09MT1I6 IGdyYXk7IEZPTlQtRkFNSUxZOiAnQ2VudHVyeSBHb3RoaWMnLCdzYW5zLXNlcmlmJyI+PFNQQU4g DQogICAgc3R5bGU9IkZPTlQtU0laRTogNy41cHQ7IENPTE9SOiBncmF5OyBGT05ULUZBTUlMWTog J0NlbnR1cnkgR290aGljJywnc2Fucy1zZXJpZiciPkxlYWQvQXJjaGl0ZWN0IA0KICAgIC0gSW50 ZWxsaWdlbnQgUHJlc2VuY2UgU2VydmVyIChJUFMpPC9TUEFOPiA8Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPSNmZjAwMDAgDQogICAgc2l6ZT0xPnw8L0ZPTlQ+Jm5ic3A7PFNQQU4gY2xhc3M9Mjc2MzQz MTE1LTA1MDgyMDA4PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9I2ZmMDAwMCBzaXplPTE+ VW5pZmllZCANCiAgICBDb21tdW5pY2F0aW9uczwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRk9OVD48 L0ZPTlQ+PFNQQU4gDQogICAgc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICdUaW1l cyBOZXcgUm9tYW4nLCdzZXJpZiciPjxCUj48L1NQQU4+PEZPTlQgDQogICAgc2l6ZT0xPjxGT05U IGZhY2U9QXJpYWw+PEZPTlQgDQogICAgY29sb3I9I2ZmMDAwMD48U1BBTj48U1RST05HPkFWQVlB PC9TVFJPTkc+Jm5ic3A7fDwvU1BBTj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiA3LjVw dDsgQ09MT1I6IGdyZWVuOyBGT05ULUZBTUlMWTogJ0NlbnR1cnkgR290aGljJywnc2Fucy1zZXJp ZiciPjxGT05UIA0KICAgIGZhY2U9QXJpYWwgc2l6ZT0xPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9G T05UPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDcuNXB0OyBDT0xPUjogZ3JlZW47IEZP TlQtRkFNSUxZOiAnQ2VudHVyeSBHb3RoaWMnLCdzYW5zLXNlcmlmJyI+PEEgDQogICAgaHJlZj0i bWFpbHRvOnNteXRoY0BhdmF5YS5jb20iPnNteXRoY0BhdmF5YS5jb208L0E+Jm5ic3A7PEZPTlQg ZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jZmYwMDAwIHNpemU9MT58PC9GT05UPjwvU1BBTj48U1BB TiANCiAgICBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21h bicsJ3NlcmlmJyI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDcu NXB0OyBDT0xPUjogZ3JheTsgRk9OVC1GQU1JTFk6ICdDZW50dXJ5IEdvdGhpYycsJ3NhbnMtc2Vy aWYnIj4rMzUzIA0KICAgIDEgNjU2IDc4NDM8L1NQQU4+PFNQQU4gDQogICAgc3R5bGU9IkNPTE9S OiBibGFjazsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZiciPjwvU1BBTj4g DQogICAgPC9GT05UPjxGT05UIGZhY2U9IkNlbnR1cnkgR290aGljIiANCmNvbG9yPSM4MDgwODA+ KHgzNzg0Myk8L0ZPTlQ+PC9GT05UPjwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PEJSPg0KICAgIDxESVYgY2xh c3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9bHRyIGFsaWduPWxlZnQ+DQog ICAgPEhSIHRhYkluZGV4PS0xPg0KICAgIDxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5Gcm9t OjwvQj4gc2ltcGxlLWJvdW5jZXNAaWV0Zi5vcmcgDQogICAgW21haWx0bzpzaW1wbGUtYm91bmNl c0BpZXRmLm9yZ10gPEI+T24gQmVoYWxmIE9mIA0KICAgIDwvQj5KYWVrd29uT0g8QlI+PEI+U2Vu dDo8L0I+IDA1IEF1Z3VzdCAyMDA4IDAyOjM0PEJSPjxCPlRvOjwvQj4gU2ltcGxlIA0KICAgIFdH PEJSPjxCPlN1YmplY3Q6PC9CPiBbU2ltcGxlXSBIb3cgdG8gc2hvdyBwcmVzZW50aXR5J3MgcmVs YXRpdmUgc2VydmljZSANCiAgICBwcmVmZXJlbmNlPEJSPjwvRk9OVD48QlI+PC9ESVY+DQogICAg PERJVj48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0y PkhpIGFsbCw8L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIHNpemU9Mj5JJ20gd29uZGVyaW5nIGhvdyBhIHByZXNlbnRpdHkgY2FuIA0K ICAgIHNob3cgaGlzIHBlcmZlcnJlZCBzZXJ2aWNlcyBpbiBwcmVzZW5jZS48QlI+QSBwb3NzaWJp bGl0eSBzZWVtcyB0byB1c2UgdGhlIA0KICAgICdwcmlvcml0eScgYXR0cmlidXRlIG9mICZsdDtj b250YWN0Jmd0OyBlbGVtZW50IGZvciB0aGlzIA0KICAgIHB1cnBvc2UuPEJSPkhvd2V2ZXIsIFJG QyAzODYzIGRlZmluZXMgdGhhdCB0aGUgJ3ByaW9yaXR5JyBhdHRyaWJ1dGUgc2hvd3MgDQogICAg dGhlIHByZXNlbnRpdHkncyBkaWZmZXJlbnQgcHJlZmVyZW5jZSBvdmVyICpjb250YWN0IGFkZHJl c3MqLCBzbyBpdCBpcyBub3QgDQogICAgY2xlYXIgd2hldGhlciB0aGlzIGlzIGdvb2QgZW5vdWdo IHRvIHNob3cgdGhlIHByZXNlbnRpdHkncyByZWxhdGl2ZSBzZXJ2aWNlIA0KICAgIHByZWZlcmVu Y2UuIDxCUj5Gb3IgZXhhbXBsZSwgd2hlbiB0aGVyZSBhcmUgbXVsdGlwbGUgU0lQIHNlcnZpY2Vz IHRoYXQgc2hhcmUgDQogICAgdGhlIHByZXNlbnRpdHkncyBBT1IgYXMgY29udGFjdCBhZGRyZXNz LCB0aGVuIGhvdyB0aGUgZGlmZmVyZW50ICdwcmlvcml0eScgDQogICAgYXR0cmlidXRlIHZhbHVl IGZvciB0aGUgc2FtZSBjb250YWN0IGFkZHJlc3Mgc2hvdWxkIGJlIGludGVycHJldGVkPzxCUj5J TUhPLCANCiAgICB0aGlzIGhhcHBlbnMgYmVjYXVzZSBhIHNlcnZpY2UgY2Fubm90IGJlIHJlcHJl c2VudGVkIG9ubHkgd2l0aCB0aGUgY29udGFjdCANCiAgICBpbmZvcm1hdGlvbi4gUmF0aGVyLCBh cyBub3RlZCBpbiBSRkMgNDQ3NiwgYSBzZXJ2aWNlIGlzIGlkZW50aWZpZWQgYnkgdGhlIA0KICAg ICJyZWFjaCBpbmZvcm1hdGlvbiIsIHdoaWNoIGlzIGEgc2V0IG9mIHByZXNlbmNlIGluZm9ybWF0 aW9uIHRvIHJlYWNoIHRoZSANCiAgICBzZXJ2aWNlIGluY2x1ZGluZyB0aGUgY29udGFjdCBhZGRy ZXNzLjwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg c2l6ZT0yPklmIHRoaXMgaXMgdGhlIGNhc2UsIHdoYXQgc2hvdWxkIHdlIA0KICAgIGRvPzxCUj48 L0RJVj48L0ZPTlQ+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTI+PC9GT05UPg0K ICAgIDxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTI+VGhhbmtzICZhbXA7 IHI8L0ZPTlQ+PEZPTlQgDQogICAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTI+ZWdhcmRz LDwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBS b21hbiIgc2l6ZT0yPkphZWt3b24gT0g8L0ZPTlQ+PC9ESVY+DQogICAgPFA+DQogICAgPEhSPg0K DQogICAgPFA+PC9QPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPEJSPlNpbXBsZSBtYWlsaW5nIA0KICAgIGxpc3Q8QlI+U2ltcGxlQGlldGYub3JnPEJSPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ltcGxlPEJSPjwvQkxPQ0tRVU9U RT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_lla9QHvRdKCbF8/fJCVL6Q)-- --===============1719202211== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============1719202211==-- From simple-bounces@ietf.org Fri Aug 8 03:01:12 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8F43A6CF0; Fri, 8 Aug 2008 03:01:12 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1838F3A6CF0 for ; Fri, 8 Aug 2008 03:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 cwwHmBab1Vyp for ; Fri, 8 Aug 2008 03:00:59 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 4D43E3A6BB9 for ; Fri, 8 Aug 2008 03:00:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,327,1215403200"; d="scan'208,217";a="117590429" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Aug 2008 06:00:51 -0400 X-IronPort-AV: E=Sophos;i="4.31,327,1215403200"; d="scan'208,217";a="253695482" Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by co300216-co-erhwest-out.avaya.com with ESMTP; 08 Aug 2008 06:00:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Aug 2008 11:00:48 +0100 Message-ID: <4C607BEA097DF048BEA625B974A3661875950E@306900ANEX2.global.avaya.com> In-Reply-To: <00e601c8f921$7848e7e0$cf1a590a@JKOH> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] How to show presentity's relative service preference Thread-Index: Acj5IYJ+0myqEFH1S9eshBL3OyNECQAGW8lA References: <005001c8f69b$54282520$cf1a590a@JKOH> <4C607BEA097DF048BEA625B974A36618730B56@306900ANEX2.global.avaya.com> <012301c8f84c$eeeb9a80$cf1a590a@JKOH> <4C607BEA097DF048BEA625B974A36618730EE1@306900ANEX2.global.avaya.com> <00e601c8f921$7848e7e0$cf1a590a@JKOH> From: "Smyth, Colm (Colm)" To: "JaekwonOH" , "Simple WG" Subject: Re: [Simple] How to show presentity's relative service preference X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0443267236==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0443267236== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F93D.A234AB60" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F93D.A234AB60 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Your scenario falls outside the scope of the present RFCs. Let's review the relevant extracts. =20 RFC 3863 says: - Relative priority: numerical value specifying the priority of this COMMUNICATION ADDRESS. (optional) and: The element contains a URL of the contact address. It optionally has a 'priority' attribute, whose value means a relative priority of this contact address over the others. The value of the attribute MUST be a decimal number between 0 and 1 inclusive with at most 3 digits after the decimal point. Higher values indicate higher priority. Examples of priority values are 0, 0.021, 0.5, 1.00. If the 'priority' attribute is omitted, applications MUST assign the contact address the lowest priority. If the 'priority' value is out of the range, applications just SHOULD ignore the value and process it as if the attribute was not present. Applications SHOULD handle contacts with a higher priority as they have precedence over those with lower priorities. How they are actually treated is beyond this specification. Also, how to handle contacts with the same priority is up to implementations. So the priority is intended to be used in combination with the contact addresss. =20 RFC 4479 says: Each service is also associated with a priority, which represents the preference that the user has for usage of one service over another. This does not mean that, when a watcher wishes to communicate with the presentity, that they should always use the service with the highest priority. If that were the case, there would be no point in including multiple services in the presence document. Rather, the priority says, "If you, the watcher, cannot decide which of these to use, or if it is not important to you, this is the order in which I would like you to contact me. However, I am giving you a choice." The priorities are relative to each other, and have no meaning as absolute numbers. If there are two services, and they have priorities of 1 and .5, respectively, this is identical to giving them priorities of .2 and .1, respectively. However clearly there is a benefit in providing presence information for multiple services, because the subscriber may have a preference for using a specific address type and so regardless they may need to treat the priority as advisory information only. =20 =20 In spite of this address-centric view of priority, I see no reason why a smart subscriber should not use all the information in the tuple (in particular, the class-id) to decide how best to address a presentity via a service, and then the priority does have meaning. =20 I see some benefit in a new RFC (or an update to RFC 4479) that clarifies this usage of priority, and that offers guidelines for class-ids, and possibly a way to communicate the mime-types supported by a given service. I'd also like to see a taxonomy of standard presence substates (e.g. do-not-disturb) and a recommendation on which substates are associated with open versus closed states. =20 I'd be interested in collaborating on any subset of these initiatives off-line and presenting some input to the WG. If anyone else is interested, please contact me directly. Jaekwon, given your insights in this thread, I hope you would consider contributing directly. =20 All the best, Colm Smyth AVAYA | smythc@avaya.com=20 =20 ________________________________ From: JaekwonOH [mailto:jaekwon.oh@samsung.com]=20 Sent: 08 August 2008 07:39 To: Simple WG; Smyth, Colm (Colm) Subject: Re: [Simple] How to show presentity's relative service preference It seems we now share the understanding that a service may not be uniquely identifiable with the contact URI only.=20 Then, the question is whether the priority attribute is still meaningful to show presentity's relative service preference.. =20 Thanks & regards, Jaekwon OH ----- Original Message -----=20 From: Smyth, Colm (Colm) =20 To: JaekwonOH ; Simple WG =20 Sent: Thursday, August 07, 2008 10:22 PM Subject: RE: [Simple] How to show presentity's relative service preference You're describing a content-based dispatch scenario; as you note, a content-oriented application isn't identifiable or addressable using a URI. =20 The tuple class-id may help with identification, however there is little guidance in the existing RFCs on what makes a good class-id. For content-dispatch over a generic protocol (e.g. SIP or even HTTP), the actual MIME-type would be useful. For other uses, it would be possible to use a similar constructive approach to create an identifier that identifies application in arbitrary levels of detail (e.g. service/protocol/vendor+version). =20 All the best, Colm Smyth AVAYA | smythc@avaya.com =20 ________________________________ From: JaekwonOH [mailto:jaekwon.oh@samsung.com]=20 Sent: 07 August 2008 06:18 To: Simple WG; Smyth, Colm (Colm) Subject: Re: [Simple] How to show presentity's relative service preference =09 =09 Hi, =20 Thanks for response. Even when the device contact URI registered for an AOR is used for tuple's contact address, the uniqueness of the contact address for a tupe seems not guaranteed. For example, a device may run multiple SIP applications, then tuples for each of those would contain the same URI. This aspect has already been clarified in RFC 4479 (see the following excerption). Therefore, IMHO, the uniquness of contact address for each tuple seem not guaranteed, so the use of 'priority' attribute of in is not enogh to show the presenity's relative service preference. =20 From RFC 4479 section 3.3.2 reach information, =20 Even for services reachable over a communications network, the URI alone may not be sufficient. For example, two applications may be running within a cellular telephone, both of which are reachable through the user's SIP Address of Record. However, one application is launched when the INVITE request contains a body of a particular type, and the other is launched for other body types. As another example, a service may provide complex application logic that operates correctly only when contacted from matching application software. In such a case, even though the communications between instances utilizes a standard protocol (such as SIP), the user experience will not be correct unless the applications are matched. When the URI is not sufficient, additional attributes of the service can be present that define the instructions on how the service is to be reached. These attributes must be understood for the service to be utilized. If a watcher receives a presence document containing reach information it does not understand, it should discard the service information. =20 =20 Thanks & regards, Jaekwon OH =09 ----- Original Message -----=20 From: Smyth, Colm (Colm) =20 To: Simple WG =20 Sent: Wednesday, August 06, 2008 1:23 AM Subject: Re: [Simple] How to show presentity's relative service preference I suggest that if there are multiple contact addresses for a single AOR, the contact element of each related tuple in PIDF should reflect a unique contact address for this AOR, not the ambiguous AOR itself. =20 A unique address is useful, not just as an identifier for the tuple's source, but to reach the address; then, the priority attribute has a meaningful scope. =20 Colm Smyth Lead/Architect - Intelligent Presence Server (IPS) | Unified Communications AVAYA | smythc@avaya.com | +353 1 656 7843 (x37843) =20 ________________________________ From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of JaekwonOH Sent: 05 August 2008 02:34 To: Simple WG Subject: [Simple] How to show presentity's relative service preference =09 =09 Hi all, =20 I'm wondering how a presentity can show his perferred services in presence. A possibility seems to use the 'priority' attribute of element for this purpose. However, RFC 3863 defines that the 'priority' attribute shows the presentity's different preference over *contact address*, so it is not clear whether this is good enough to show the presentity's relative service preference.=20 For example, when there are multiple SIP services that share the presentity's AOR as contact address, then how the different 'priority' attribute value for the same contact address should be interpreted? IMHO, this happens because a service cannot be represented only with the contact information. Rather, as noted in RFC 4476, a service is identified by the "reach information", which is a set of presence information to reach the service including the contact address. If this is the case, what should we do? =09 =09 Thanks & regards, =20 Jaekwon OH =09 ________________________________ =09 _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple =09 ------_=_NextPart_001_01C8F93D.A234AB60 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Your scenario falls outside the scope of the = present RFCs.=20 Let's review the relevant extracts.
 
RFC 3863 says:
     - =
Relative priority: numerical value specifying the priority
         of this COMMUNICATION ADDRESS. (optional)
and:
   The =
<contact> element contains a URL of the contact address.  It
   optionally has a 'priority' attribute, whose value means a relative
   priority of this contact address over the others.  The value of the
   attribute MUST be a decimal number between 0 and 1 inclusive with at
   most 3 digits after the decimal point.  Higher values indicate higher
   priority.  Examples of priority values are 0, 0.021, 0.5, 1.00. If
   the 'priority' attribute is omitted, applications MUST assign the
   contact address the lowest priority.  If the 'priority' value is out
   of the range, applications just SHOULD ignore the value and process
   it as if the attribute was not present.

   Applications SHOULD handle contacts with a higher priority as they
   have precedence over those with lower priorities.  How they are
   actually treated is beyond this specification.  Also, how to handle
   contacts with the same priority is up to =
implementations.
So the priority is intended to be used in = combination with=20 the contact addresss.
 
RFC 4479 says:
   =
Each service is also associated with a priority, which represents the
   preference that the user has for usage of one service over another.
   This does not mean that, when a watcher wishes to communicate with
   the presentity, that they should always use the service with the
   highest priority.  If that were the case, there would be no point in
   including multiple services in the presence document.  Rather, the
   priority says, "If you, the watcher, cannot decide which of these to
   use, or if it is not important to you, this is the order in which I
   would like you to contact me.  However, I am giving you a choice."
   The priorities are relative to each other, and have no meaning as
   absolute numbers.  If there are two services, and they have
   priorities of 1 and .5, respectively, this is identical to giving
   them priorities of .2 and .1, respectively.
However clearly there is a benefit in = providing=20 presence information for multiple services, because the subscriber may = have a=20 preference for using a specific address type and so regardless they may = need to=20 treat the priority as advisory information only.
 
 
In=20 spite of this address-centric view of priority, I see no reason why a = smart=20 subscriber should not use all the information in the tuple (in = particular, the=20 class-id) to decide how best to address a presentity via a service, and = then the=20 priority does have meaning.
 
I see=20 some benefit in a new RFC (or an update to RFC 4479) that clarifies this = usage=20 of priority, and that offers guidelines for class-ids, and possibly a = way to=20 communicate the mime-types supported by a given service. I'd also like = to see a=20 taxonomy of standard presence substates (e.g. do-not-disturb) and a=20 recommendation on which substates are associated with open versus closed = states.
 
I'd be=20 interested in collaborating on any subset of these initiatives off-line = and=20 presenting some input to the WG. If anyone else is interested, please = contact me=20 directly. Jaekwon, given your insights in this thread, I hope you would = consider=20 contributing directly.
 
All=20 the best,
Colm Smyth
AVAYA | smythc@avaya.com =
 

From: JaekwonOH = [mailto:jaekwon.oh@samsung.com]=20
Sent: 08 August 2008 07:39
To: Simple WG; Smyth, = Colm=20 (Colm)
Subject: Re: [Simple] How to show presentity's relative = service=20 preference

It seems we now share the = understanding that a service may not be uniquely identifiable with the = contact=20 URI only.
Then, the question is whether the priority = attribute is=20 still meaningful to show presentity's relative service = preference..
 
Thanks & regards,
Jaekwon OH
----- Original Message = -----
From: Smyth, Colm = (Colm)=20
Sent: Thursday, = August 07, 2008 10:22=20 PM
Subject: RE: = [Simple] How to show=20 presentity's relative service preference

You're describing a content-based dispatch = scenario;=20 as you note, a content-oriented application isn't identifiable or = addressable=20 using a URI.
 
The tuple class-id may help with = identification,=20 however there is little guidance in the existing RFCs on what makes a = good=20 class-id. For content-dispatch over a generic = protocol (e.g.=20 SIP or even HTTP), the actual MIME-type would be useful. For other = uses, it=20 would be possible to use a similar constructive approach to create an=20 identifier that identifies application in arbitrary levels of detail = (e.g.=20 service/protocol/vendor+version).
 
All=20 the best,
Colm Smyth
AVAYA | smythc@avaya.com
 

From: JaekwonOH=20 [mailto:jaekwon.oh@samsung.com]
Sent: 07 August 2008=20 06:18
To: Simple WG; Smyth, Colm (Colm)
Subject: = Re:=20 [Simple] How to show presentity's relative service=20 preference

Hi,
 
Thanks for response.
Even when the device contact URI = registered for an=20 AOR is used for tuple's contact address, the uniqueness of the = contact=20 address for a tupe seems not guaranteed. For example, a device = may=20 run multiple SIP applications, then tuples for each of those = would=20 contain the same URI.
This aspect has already been clarified in RFC 4479 = (see the=20 following excerption).
Therefore, IMHO, the uniquness of contact address = for each=20 tuple seem not guaranteed, so the use of 'priority' attribute of=20 <contact> in <tuple> is not enogh to show the presenity's = relative=20 service preference.
 
From RFC 4479 section 3.3.2 reach=20 information,
 
Even for services reachable over a communications = network,=20 the URI
alone may not be sufficient. For example, two applications = may=20 be
running within a cellular telephone, both of which are=20 reachable
through the user’s SIP Address of Record. However, = one=20 application
is launched when the INVITE request contains a body of = a=20 particular
type, and the other is launched for other body types. As = another
example, a service may provide complex application logic=20 that
operates correctly only when contacted from matching=20 application
software. In such a case, even though the = communications=20 between
instances utilizes a standard protocol (such as SIP), the=20 user
experience will not be correct unless the applications are=20 matched.
When the URI is not sufficient, additional attributes of = the=20 service
can be present that define the instructions on how the = service is=20 to
be reached. These attributes must be understood for the service = to
be=20 utilized. If a watcher receives a presence document = containing
reach=20 information it does not understand, it should discard the
service=20 information.
 
 
Thanks & regards,
Jaekwon OH
----- Original Message -----
From:=20 Smyth, = Colm=20 (Colm)
Sent: Wednesday, = August 06, 2008 1:23=20 AM
Subject: Re: = [Simple] How to show=20 presentity's relative service preference

I suggest that if there are multiple = contact=20 addresses for a single AOR, the contact element of each related = tuple in=20 PIDF should reflect a unique contact address for this AOR, not the = ambiguous=20 AOR itself.
 
A unique address is useful, not just as = an=20 identifier for the tuple's source, but to reach the address; then, = the=20 priority attribute has a meaningful scope.
 
Colm Smyth
Lead/Architect=20 - Intelligent Presence Server (IPS) | Unified=20 Communications
AVAYA | smythc@avaya.com | +353=20 1 656 7843=20 (x37843)
 

From: simple-bounces@ietf.org=20 [mailto:simple-bounces@ietf.org] On Behalf Of=20 JaekwonOH
Sent: 05 August 2008 02:34
To: = Simple=20 WG
Subject: [Simple] How to show presentity's relative = service=20 preference

Hi all,
 
I'm wondering how a = presentity can=20 show his perferred services in presence.
A possibility seems to = use the=20 'priority' attribute of <contact> element for this=20 purpose.
However, RFC 3863 defines that the 'priority' attribute = shows=20 the presentity's different preference over *contact address*, so it = is not=20 clear whether this is good enough to show the presentity's relative = service=20 preference.
For example, when there are multiple SIP services = that share=20 the presentity's AOR as contact address, then how the different = 'priority'=20 attribute value for the same contact address should be = interpreted?
IMHO,=20 this happens because a service cannot be represented only with the = contact=20 information. Rather, as noted in RFC 4476, a service is identified = by the=20 "reach information", which is a set of presence information to reach = the=20 service including the contact address.
If this is the case, = what should we=20 do?
Thanks & = regards,
 
Jaekwon OH

_______________________________________________
Simple = mailing=20 = list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple
------_=_NextPart_001_01C8F93D.A234AB60-- --===============0443267236== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============0443267236==-- From simple-bounces@ietf.org Fri Aug 8 05:45:26 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C8928C11B; Fri, 8 Aug 2008 05:45:20 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4C563A6AEA for ; Fri, 8 Aug 2008 05:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Vn9G1ccnS5ZM for ; Fri, 8 Aug 2008 05:45:01 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 093593A6C95 for ; Fri, 8 Aug 2008 05:45:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,327,1215388800"; d="scan'208";a="16889133" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 08 Aug 2008 12:44:58 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m78CiwNs022383; Fri, 8 Aug 2008 08:44:58 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m78Ciw2t025311; Fri, 8 Aug 2008 12:44:58 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 08:44:58 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 08:44:57 -0400 Message-ID: <489C4001.6070303@cisco.com> Date: Fri, 08 Aug 2008 08:45:53 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: JaekwonOH References: <005001c8f69b$54282520$cf1a590a@JKOH> <4C607BEA097DF048BEA625B974A36618730B56@306900ANEX2.global.avaya.com> <012301c8f84c$eeeb9a80$cf1a590a@JKOH> <489AE135.4050000@cisco.com> <00e201c8f921$4d33b350$cf1a590a@JKOH> In-Reply-To: <00e201c8f921$4d33b350$cf1a590a@JKOH> X-OriginalArrivalTime: 08 Aug 2008 12:44:57.0727 (UTC) FILETIME=[908518F0:01C8F954] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6434; t=1218199498; x=1219063498; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20How=20to=20show=20presentity 's=20relative=20service=20preference |Sender:=20 |To:=20JaekwonOH=20; bh=cCeGICaahNSQM4chmIJ9rMCJFztBsA32gMFtPq3WEuM=; b=RbYyvrRlPkirOMXJ1WaX10kXkHRIUarE9uz9z/2JBSXmnsoTHIm/Lm8Aes hAIr82sVJsnaLr83KvWOpdTu5Wl/Hcq6uaq7NF65uEIptGSP1PFuitdE44mG yS2GeJzzSW; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Simple WG Subject: Re: [Simple] How to show presentity's relative service preference X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org JaekwonOH wrote: > Thanks for comment. > = >> Only if it wants them to. It certainly may use a separate contact uri = >> for each application. (They probably have the same address and are = >> distinguished by the user part, or port.) Its the responsibility of the = >> application to put in enough uniqueness to get proper results. > = > I agree that if all each application can have unique contact address then= there's no problem. > However, as I understand relevant RFCs incl. RFC4479, this seems not alwa= ys the case. = What would lead you to think you can't have as many unique addresses as = you want? > So, when the contact address is not unique over different applications, i= t is questionable whether the priority attribute can be still meaningful to= show presentity's relative service preference... > = > Thanks & regards, > Jaekwon OH > = > ----- Original Message ----- = > From: "Paul Kyzivat" > To: "JaekwonOH" > Cc: "Simple WG" ; "Smyth, Colm (Colm)" > Sent: Thursday, August 07, 2008 8:49 PM > Subject: Re: [Simple] How to show presentity's relative service preference > = > = >> >> JaekwonOH wrote: >>> Hi, >>> = >>> Thanks for response. >>> Even when the device contact URI registered for an AOR is used for = >>> tuple's contact address, the uniqueness of the contact address for a = >>> tupe seems not guaranteed. For example, a device may run multiple SIP = >>> applications, then tuples for each of those would contain the same URI. >> Only if it wants them to. It certainly may use a separate contact uri = >> for each application. (They probably have the same address and are = >> distinguished by the user part, or port.) Its the responsibility of the = >> application to put in enough uniqueness to get proper results. >> >> Paul >> >>> This aspect has already been clarified in RFC 4479 (see the following = >>> excerption). >>> Therefore, IMHO, the uniquness of contact address for each tuple seem = >>> not guaranteed, so the use of 'priority' attribute of in = >>> is not enogh to show the presenity's relative service preferenc= e. >>> = >>> From RFC 4479 section 3.3.2 reach information, >>> = >>> Even for services reachable over a communications network, the URI >>> alone may not be sufficient. For example, two applications may be >>> running within a cellular telephone, both of which are reachable >>> through the user=92s SIP Address of Record. However, one application >>> is launched when the INVITE request contains a body of a particular >>> type, and the other is launched for other body types. As another >>> example, a service may provide complex application logic that >>> operates correctly only when contacted from matching application >>> software. In such a case, even though the communications between >>> instances utilizes a standard protocol (such as SIP), the user >>> experience will not be correct unless the applications are matched. >>> When the URI is not sufficient, additional attributes of the service >>> can be present that define the instructions on how the service is to >>> be reached. These attributes must be understood for the service to >>> be utilized. If a watcher receives a presence document containing >>> reach information it does not understand, it should discard the >>> service information. >>> = >>> = >>> Thanks & regards, >>> Jaekwon OH >>> ----- Original Message ----- >>> >>> *From:* Smyth, Colm (Colm) >>> *To:* Simple WG >>> *Sent:* Wednesday, August 06, 2008 1:23 AM >>> *Subject:* Re: [Simple] How to show presentity's relative service >>> preference >>> >>> I suggest that if there are multiple contact addresses for a single >>> AOR, the contact element of each related tuple in PIDF should >>> reflect a unique contact address for this AOR, not the ambiguous AOR >>> itself. >>> = >>> A unique address is useful, not just as an identifier for the >>> tuple's source, but to reach the address; then, the priority >>> attribute has a meaningful scope. >>> = >>> Colm Smyth >>> Lead/Architect - Intelligent Presence Server (IPS) | Unified >>> Communications >>> *AVAYA* | smythc@avaya.com | +353 1 656 >>> 7843 (x37843) >>> = >>> >>> -------------------------------------------------------------------= ----- >>> *From:* simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] *On >>> Behalf Of *JaekwonOH >>> *Sent:* 05 August 2008 02:34 >>> *To:* Simple WG >>> *Subject:* [Simple] How to show presentity's relative service prefe= rence >>> >>> Hi all, >>> = >>> I'm wondering how a presentity can show his perferred services in >>> presence. >>> A possibility seems to use the 'priority' attribute of >>> element for this purpose. >>> However, RFC 3863 defines that the 'priority' attribute shows the >>> presentity's different preference over *contact address*, so it is >>> not clear whether this is good enough to show the presentity's >>> relative service preference. >>> For example, when there are multiple SIP services that share the >>> presentity's AOR as contact address, then how the different >>> 'priority' attribute value for the same contact address should be >>> interpreted? >>> IMHO, this happens because a service cannot be represented only with >>> the contact information. Rather, as noted in RFC 4476, a service is >>> identified by the "reach information", which is a set of presence >>> information to reach the service including the contact address. >>> If this is the case, what should we do? >>> Thanks & regards, >>> = >>> Jaekwon OH >>> >>> -------------------------------------------------------------------= ----- >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Aug 12 08:06:12 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6568F3A6B6F; Tue, 12 Aug 2008 08:06:12 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B57F3A6ACE for ; Tue, 12 Aug 2008 08:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.343 X-Spam-Level: X-Spam-Status: No, score=-3.343 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 JebCpSgB4gHi for ; Tue, 12 Aug 2008 08:06:06 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 59C123A6A5F for ; Tue, 12 Aug 2008 08:06:05 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id A673E58244 for ; Tue, 12 Aug 2008 11:05:28 -0400 (EDT) X-AuditID: 0a401fcb-a6a2bbb0000057be-41-48a1a6b74216 Received: from XCH21YKF.rim.net (unknown [10.102.100.36]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id 0A8AB582C2 for ; Tue, 12 Aug 2008 11:05:27 -0400 (EDT) Received: from XCH67YKF.rim.net ([10.64.31.86]) by XCH21YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Aug 2008 11:05:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Aug 2008 11:05:25 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: How to show presentity's relative service preference Thread-Index: Acj8jNk/7hiwx+P/TcS/UC8w9Aktyw== From: "Brian McColgan" To: X-OriginalArrivalTime: 12 Aug 2008 15:05:26.0631 (UTC) FILETIME=[DA30C770:01C8FC8C] X-Brightmail-Tracker: AAAAAQs469Y= Subject: Re: [Simple] How to show presentity's relative service preference X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2128572178==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============2128572178== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8FC8C.D9C9428C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8FC8C.D9C9428C Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hi all, There seems to be a few issues 'at work' here, and the discussion 'so far' may be trying to merge several problems together. The first is unambiguously trying to identify a contact for an associated service/application. Not sure whether this is an issue, may be more of a 'best practice' or 'prescribed guideline' on how to achieve this. How does a watcher interpret or deal with the 'contact' element in scenarios whereby one tuple (corresponding to a presentity) may not have any contact elements? IETF rfc3863 (section 4.1.5) seems to try and steer away from defining the scope of a 'contact' element in one tuple and it's applicability or scope within another. Finally, how do we go about identifying or expressing a presentities preference for one service over another? Do we need to include a separate indication of 'service preference' in the context of PIDF _OR_ is there sufficient detail within the PIDF to infer or derive a given presentities preference for one service, versus another similar service (e.g. my preference of Google Talk over MSN)? Perhaps this will help provide a 'frame of reference' for our SIP/SIMPLE experts within the IETF to help provide some guidance or recommendations. Kind Regards, Brian. ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01C8FC8C.D9C9428C Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hi all,

 

There seems to be a few issues ‘at work’ here= , and the discussion ‘so far’ may be trying to merge several probl= ems together. 

 

The first is unambiguously trying to identify a contact f= or an associated service/application.  Not sure whether this is an issue,= may be more of a ‘best practice’ or ‘prescribed guideline̵= 7; on how to achieve this. 

 

How does a watcher interpret or deal with the ‘cont= act’ element in scenarios whereby one tuple (corresponding to a presentity) may n= ot have any contact elements?  IETF rfc3863 (section 4.1.5) seems to try a= nd steer away from defining the scope of a ‘contact’ element in one tuple and it’s applicability or scope within another. 

 

Finally, how do we go about identifying or expressing a presentities preference for one service over another?  Do we need to include a separate indication of ‘service preference’ in the con= text of PIDF _OR_ is there suffic= ient detail within the PIDF to infer or derive a given presentities preference fo= r one service, versus another similar service (e.g. my preference of Google Ta= lk over MSN)?

 

Perhaps this will help provide a ‘frame of referenc= e’ for our SIP/SIMPLE experts within the IETF to help provide some guidance or recommendations.

 

Kind Regards,

Brian.

 

 

---------------------------------------------------------------------
= =0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01C8FC8C.D9C9428C-- --===============2128572178== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============2128572178==-- From simple-bounces@ietf.org Wed Aug 13 05:05:08 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6BC3A6A18; Wed, 13 Aug 2008 05:05:08 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE963A6A18 for ; Wed, 13 Aug 2008 05:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 GCMdNWJ9tt0F for ; Wed, 13 Aug 2008 05:05:05 -0700 (PDT) Received: from web65401.mail.ac4.yahoo.com (web65401.mail.ac4.yahoo.com [76.13.9.21]) by core3.amsl.com (Postfix) with SMTP id 865873A68A1 for ; Wed, 13 Aug 2008 05:05:05 -0700 (PDT) Received: (qmail 22018 invoked by uid 60001); 13 Aug 2008 12:04:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=VRnYTYOhCqcolH0A/XmO/DJBs3LPnu6ug5EcrTArmfJc+I6xxUCZzU6C+rKV4kypbgOPnaUqrsYfDGKE8jn+NPRktbVJYIPalg3TXQqRTof9McmxmXtEb4jnPGPgWByDnjqLcf+T8LnT9Jvhdf7OX+aBBWilhOk7T2NrwSfxt0A=; X-YMail-OSG: EkgHZ1AVM1lygCVx2IVYlqw7asL9AwhdXluRjAWfq4GBfOgatDCBYNrie3J8GlMlhg7XpABjLXG20uYuncQ8KaLPE10NPgrC6FvsW91Ft2Q72GLoihPwgj0UM3m_98Ni5LM- Received: from [203.126.136.223] by web65401.mail.ac4.yahoo.com via HTTP; Wed, 13 Aug 2008 05:04:23 PDT Date: Wed, 13 Aug 2008 05:04:23 -0700 (PDT) From: manju kori To: simple@ietf.org MIME-Version: 1.0 Message-ID: <491167.21986.qm@web65401.mail.ac4.yahoo.com> Subject: [Simple] Doubt in aborting the MSRP message transfer X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0615770937==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============0615770937== Content-Type: multipart/alternative; boundary="0-329428351-1218629063=:21986" Content-Transfer-Encoding: 8bit --0-329428351-1218629063=:21986 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello All, I have a doubt in Abort procedure used in MSRP Protocol. Scenario is, I have active message (ex: file/buffer) transfer going on, and the message receiver aborted the transfer, then according to RFC, it should send response 413 to the sender. My question is, Does Receiver endpoint need to generate new transaction id for this 413 response? Or it need to get the trasaction id from previous chunk received for that perticular message? Thanks in advance -Manju --0-329428351-1218629063=:21986 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello All,
 
I have a doubt in Abort procedure used in MSRP Protocol.
 
Scenario is, I have active message (ex: file/buffer) transfer going on, and the message receiver aborted the transfer, then according to RFC, it should send response 413 to the sender.
 
My question is,
 Does Receiver endpoint need to generate new transaction id for this 413 response? Or it need to get the trasaction id from previous chunk received for that perticular message?
 
Thanks in advance
-Manju

--0-329428351-1218629063=:21986-- --===============0615770937== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============0615770937==-- From simple-bounces@ietf.org Wed Aug 13 10:40:00 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF4283A6B24; Wed, 13 Aug 2008 10:40:00 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 223E13A6B24; Wed, 13 Aug 2008 10:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.013 X-Spam-Level: X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 6CS6C+wCIFXI; Wed, 13 Aug 2008 10:39:58 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 7E91C3A6A01; Wed, 13 Aug 2008 10:39:55 -0700 (PDT) Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m7DHdcC05427; Wed, 13 Aug 2008 17:39:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 12:37:04 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC Review: draft-ietf-sipping-presence-scaling-requirements-01.txt thread-index: Acj9azMkIJeBtU0/Q/aY56hzHLdf3w== From: "Mary Barnes" To: Cc: draft-ietf-sipping-presence-scaling@tools.ietf.org, Gonzalo Camarillo , simple mailing list Subject: [Simple] WGLC Review: draft-ietf-sipping-presence-scaling-requirements-01.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1733891400==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1733891400== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8FD6B.8C56AC60" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8FD6B.8C56AC60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, This is to announce a Working Group Last Call on the following document to be published as Informational: http://www.ietf.org/internet-drafts/draft-ietf-sipping-presence-scaling- requirements-01.txt The review period will end on 3 Sept 2008 (3 weeks time).=20 Note that I have cross-posted to the SIMPLE WG, but ask that you please send your comments only to the SIPPING WG mailing list and authors. At this point we only have one reviewer that has volunteered: Vijay Gurbani We need at least two others and a presence expert (per RAI review process).=20 And, we do encourage others to review and make any final comments on the document at this time (including the very useful "Ready" comment).=20 Thanks, Mary SIPPING WG co-chair As a reminder, the SIPPING WG review guidelines are available at: https://softarmor.com/sipping/process/wg-review/sipping-review-guideline s.html ------_=_NextPart_001_01C8FD6B.8C56AC60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WGLC Review: = draft-ietf-sipping-presence-scaling-requirements-01.txt

Hi folks,

This is to announce a Working = Group Last Call on the following document to be published as = Informational:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-presence-scal= ing-requirements-01.txt

The review period will end on 3 = Sept 2008 (3 weeks time).

Note that I have cross-posted to = the SIMPLE WG, but ask that you please send your comments only to the = SIPPING WG mailing list and authors.

At this point we only have one = reviewer that has volunteered:  Vijay Gurbani
We need at least two others and = a presence expert (per RAI review process).

And, we do encourage others to = review and make any final comments on the document at this time = (including the very useful "Ready" comment).

Thanks,
Mary
SIPPING WG co-chair

As a reminder, the SIPPING WG = review guidelines are available at:
https://softarmor.com/sipping/process/wg-review/sipping-review-guide= lines.html

------_=_NextPart_001_01C8FD6B.8C56AC60-- --===============1733891400== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============1733891400==-- From simple-bounces@ietf.org Wed Aug 13 16:46:17 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A5B33A6D30; Wed, 13 Aug 2008 16:46:17 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCF913A6D30 for ; Wed, 13 Aug 2008 16:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.248 X-Spam-Level: X-Spam-Status: No, score=-0.248 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RELAY_IS_203=0.994] 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 Uuwst7U9BcHZ for ; Wed, 13 Aug 2008 16:46:15 -0700 (PDT) Received: from mailout4.samsung.com (mailout4.samsung.com [203.254.224.34]) by core3.amsl.com (Postfix) with ESMTP id 6614D3A6D13 for ; Wed, 13 Aug 2008 16:46:15 -0700 (PDT) Received: from epmmp2 (mailout4.samsung.com [203.254.224.34]) by mailout4.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K5K00ATNCODIB@mailout4.samsung.com> for simple@ietf.org; Thu, 14 Aug 2008 08:45:49 +0900 (KST) Received: from JKOH ([10.89.26.207]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0K5K007V7COC68@mmp2.samsung.com> for simple@ietf.org; Thu, 14 Aug 2008 08:45:49 +0900 (KST) Date: Thu, 14 Aug 2008 08:45:41 +0900 From: JaekwonOH To: Paul Kyzivat Message-id: <001c01c8fd9e$b1df7150$cf1a590a@JKOH> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <005001c8f69b$54282520$cf1a590a@JKOH> <4C607BEA097DF048BEA625B974A36618730B56@306900ANEX2.global.avaya.com> <012301c8f84c$eeeb9a80$cf1a590a@JKOH> <489AE135.4050000@cisco.com> <00e201c8f921$4d33b350$cf1a590a@JKOH> <489C4001.6070303@cisco.com> Cc: Simple WG Subject: Re: [Simple] How to show presentity's relative service preference X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi Paul, > What would lead you to think you can't have as many unique addresses as = > you want? SIP applications for a registered user (i.e., presentity), such as voip, pt= t, and im. They can share the user's SIP AOR as contact address, and be dif= ferentiated each other with different feature tags. = Thanks & regards, Jaekwon OH ----- Original Message ----- = From: "Paul Kyzivat" To: "JaekwonOH" Cc: "Smyth, Colm (Colm)" ; "Simple WG" Sent: Friday, August 08, 2008 9:45 PM Subject: Re: [Simple] How to show presentity's relative service preference > = > = > JaekwonOH wrote: >> Thanks for comment. >> = >>> Only if it wants them to. It certainly may use a separate contact uri = >>> for each application. (They probably have the same address and are = >>> distinguished by the user part, or port.) Its the responsibility of the = >>> application to put in enough uniqueness to get proper results. >> = >> I agree that if all each application can have unique contact address the= n there's no problem. >> However, as I understand relevant RFCs incl. RFC4479, this seems not alw= ays the case. = > = > What would lead you to think you can't have as many unique addresses as = > you want? > = >> So, when the contact address is not unique over different applications, = it is questionable whether the priority attribute can be still meaningful t= o show presentity's relative service preference... >> = >> Thanks & regards, >> Jaekwon OH >> = >> ----- Original Message ----- = >> From: "Paul Kyzivat" >> To: "JaekwonOH" >> Cc: "Simple WG" ; "Smyth, Colm (Colm)" >> Sent: Thursday, August 07, 2008 8:49 PM >> Subject: Re: [Simple] How to show presentity's relative service preferen= ce >> = >> = >>> >>> JaekwonOH wrote: >>>> Hi, >>>> = >>>> Thanks for response. >>>> Even when the device contact URI registered for an AOR is used for = >>>> tuple's contact address, the uniqueness of the contact address for a = >>>> tupe seems not guaranteed. For example, a device may run multiple SIP = >>>> applications, then tuples for each of those would contain the same URI. >>> Only if it wants them to. It certainly may use a separate contact uri = >>> for each application. (They probably have the same address and are = >>> distinguished by the user part, or port.) Its the responsibility of the = >>> application to put in enough uniqueness to get proper results. >>> >>> Paul >>> >>>> This aspect has already been clarified in RFC 4479 (see the following = >>>> excerption). >>>> Therefore, IMHO, the uniquness of contact address for each tuple seem = >>>> not guaranteed, so the use of 'priority' attribute of in = >>>> is not enogh to show the presenity's relative service preferen= ce. >>>> = >>>> From RFC 4479 section 3.3.2 reach information, >>>> = >>>> Even for services reachable over a communications network, the URI >>>> alone may not be sufficient. For example, two applications may be >>>> running within a cellular telephone, both of which are reachable >>>> through the user=92s SIP Address of Record. However, one application >>>> is launched when the INVITE request contains a body of a particular >>>> type, and the other is launched for other body types. As another >>>> example, a service may provide complex application logic that >>>> operates correctly only when contacted from matching application >>>> software. In such a case, even though the communications between >>>> instances utilizes a standard protocol (such as SIP), the user >>>> experience will not be correct unless the applications are matched. >>>> When the URI is not sufficient, additional attributes of the service >>>> can be present that define the instructions on how the service is to >>>> be reached. These attributes must be understood for the service to >>>> be utilized. If a watcher receives a presence document containing >>>> reach information it does not understand, it should discard the >>>> service information. >>>> = >>>> = >>>> Thanks & regards, >>>> Jaekwon OH >>>> ----- Original Message ----- >>>> >>>> *From:* Smyth, Colm (Colm) >>>> *To:* Simple WG >>>> *Sent:* Wednesday, August 06, 2008 1:23 AM >>>> *Subject:* Re: [Simple] How to show presentity's relative service >>>> preference >>>> >>>> I suggest that if there are multiple contact addresses for a single >>>> AOR, the contact element of each related tuple in PIDF should >>>> reflect a unique contact address for this AOR, not the ambiguous A= OR >>>> itself. >>>> = >>>> A unique address is useful, not just as an identifier for the >>>> tuple's source, but to reach the address; then, the priority >>>> attribute has a meaningful scope. >>>> = >>>> Colm Smyth >>>> Lead/Architect - Intelligent Presence Server (IPS) | Unified >>>> Communications >>>> *AVAYA* | smythc@avaya.com | +353 1 656 >>>> 7843 (x37843) >>>> = >>>> >>>> ------------------------------------------------------------------= ------ >>>> *From:* simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] *= On >>>> Behalf Of *JaekwonOH >>>> *Sent:* 05 August 2008 02:34 >>>> *To:* Simple WG >>>> *Subject:* [Simple] How to show presentity's relative service pref= erence >>>> >>>> Hi all, >>>> = >>>> I'm wondering how a presentity can show his perferred services in >>>> presence. >>>> A possibility seems to use the 'priority' attribute of >>>> element for this purpose. >>>> However, RFC 3863 defines that the 'priority' attribute shows the >>>> presentity's different preference over *contact address*, so it is >>>> not clear whether this is good enough to show the presentity's >>>> relative service preference. >>>> For example, when there are multiple SIP services that share the >>>> presentity's AOR as contact address, then how the different >>>> 'priority' attribute value for the same contact address should be >>>> interpreted? >>>> IMHO, this happens because a service cannot be represented only wi= th >>>> the contact information. Rather, as noted in RFC 4476, a service is >>>> identified by the "reach information", which is a set of presence >>>> information to reach the service including the contact address. >>>> If this is the case, what should we do? >>>> Thanks & regards, >>>> = >>>> Jaekwon OH >>>> >>>> ------------------------------------------------------------------= ------ >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>>> >>>> >>>> ----------------------------------------------------------------------= -- >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 13 17:06:11 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F0ED3A6A84; Wed, 13 Aug 2008 17:06:11 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910B03A6D30 for ; Wed, 13 Aug 2008 17:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 cT5J1HIqLBKG for ; Wed, 13 Aug 2008 17:06:08 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 2B8A33A6891 for ; Wed, 13 Aug 2008 17:06:08 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so168183fga.41 for ; Wed, 13 Aug 2008 17:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=N1cxS3tXvl8N5JWSx+SjcM49+lG3oFQtiHPKEuHj61s=; b=uQ4LHxBawFryCNandKrftcnpQHPbxazc6P0Za4Mggu7cICOV5JfjXCaxjP/dqdDpVw rAXkJ+181bknGTvYVCDlcT4KIkIZo/eoqANaMmv5YgKlrfvZE2lGvspQqe8UVyg7cWq6 y0jpswyaJLaCZIpMwdm3uz8KccqaNY/2KxXtM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=FWhd0ECb4xraP2PyLYR4Df1XoKuAgYRZrDJ45NXPQO4WKeCaGwLemBwXml+QuT2iUt NXcfuG83f01hf23lnT+QBam44xrVvSFVQWa2Ph5HksPuLQszEE3IDWm6T1lS3gMLhglQ dv22DpIK5EqjBQqaDl3nsubU5tvap0ztP51IA= Received: by 10.86.30.9 with SMTP id d9mr781985fgd.37.1218672367093; Wed, 13 Aug 2008 17:06:07 -0700 (PDT) Received: by 10.86.94.13 with HTTP; Wed, 13 Aug 2008 17:06:07 -0700 (PDT) Message-ID: Date: Thu, 14 Aug 2008 01:06:07 +0100 From: "Eduardo Martins" To: simple@ietf.org MIME-Version: 1.0 Subject: [Simple] Mobicents SIP Presence Service 1.0.0.BETA2 released! X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1798476354==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1798476354== Content-Type: multipart/alternative; boundary="----=_Part_90151_17092128.1218672367094" ------=_Part_90151_17092128.1218672367094 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline We are happy to announce Mobicents SIP Presence Service 1.0.0.BETA2! Release Notes ------------------------------------------------------------------------------- Mobicents SIP Presence Service is composed by Mobicents XDM and Presence Servers, on this release you can find: * Mobicents XDM Server standalone installed in JBboss AS + Mobicents JAIN SLEE Server (mobicents-sip-presence-xdms-.zip) * Mobicents XDM Server and Mobicents SIP Presence Servers integrated installed in JBboss AS + Mobicents JAIN SLEE Server (mobicents-sip-presence-integrated-.zip) * Mobicents SIP Presence Service binary package that you can use to install XDM or Integrated servers in JBoss AS + Mobicents JAIN SLEE Server (mobicents-sip-presence-.zip) * Mobicents SIP Presence Service source project that you can use to build and install XDM or Integrated servers in JBoss AS + Mobicents JAIN SLEE Server (mobicents-sip-presence--src.zip) Where to download from? ------------------------------------------------------------------------------- The distribution can be found on SourceForge.net. URL: https://sourceforge.net/project/showfiles.php?group_id=102670&package_id=287660&release_id=619669 SVN tag: mobicents-sip-presence-service-1.0.0.BETA2 Source repositories: ------------------------------------------------------------------------------- http://mobicents.googlecode.com/svn/trunk/servers/sip-presence How to get started: ------------------------------------------------------------------------------- The servers that are bundled with JBoss AS just need to be started as usual. For binary or source packages see the README file in the top directory of the zip file. Any other directory where additional instructions are needed has its own README file. Documentation ------------------------------------------------------------------------------- http://groups.google.com/group/mobicents-public/web/mobicents-sip-presence-service-guide Change Log ------------------------------------------------------------------------------- This is actually the first binary release of the servers, so everything is new! See full specs, architecture, etc. at http://groups.google.com/group/mobicents-public/web/mobicents-sip-presence-service-guide Looking forward to your feedback!!! Mobicents/JBoss Communication Platform Team ------=_Part_90151_17092128.1218672367094 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
We are happy to announce Mobicents SIP Presence Service 1.0.0.BETA2!

Release Notes
-------------------------------------------------------------------------------
Mobicents SIP Presence Service is composed by Mobicents XDM and Presence Servers, on this release you can find:
* Mobicents XDM Server standalone installed in JBboss AS + Mobicents JAIN SLEE Server (mobicents-sip-presence-xdms-<version>.zip)
* Mobicents XDM Server and Mobicents SIP Presence Servers integrated installed in JBboss AS + Mobicents JAIN SLEE Server (mobicents-sip-presence-integrated-<version>.zip)
* Mobicents SIP Presence Service binary package that you can use to install XDM or Integrated servers in JBoss AS + Mobicents JAIN SLEE Server (mobicents-sip-presence-<version>.zip)
* Mobicents SIP Presence Service source project that you can use to build and install XDM or Integrated servers in JBoss AS + Mobicents JAIN SLEE Server (mobicents-sip-presence-<version>-src.zip)

Where to download from?
-------------------------------------------------------------------------------
The distribution can be found on SourceForge.net.
URL: https://sourceforge.net/project/showfiles.php?group_id=102670&package_id=287660&release_id=619669

SVN tag: mobicents-sip-presence-service-1.0.0.BETA2

Source repositories:
-------------------------------------------------------------------------------
http://mobicents.googlecode.com/svn/trunk/servers/sip-presence

How to get started:
-------------------------------------------------------------------------------
The servers that are bundled with JBoss AS just need to be started as usual.
For binary or source packages see the README file in the top directory of the zip file.
Any other directory where additional instructions are needed has its own README file.

Documentation
-------------------------------------------------------------------------------
http://groups.google.com/group/mobicents-public/web/mobicents-sip-presence-service-guide

Change Log
-------------------------------------------------------------------------------
This is actually the first binary release of the servers, so everything is new! See full specs, architecture, etc. at
http://groups.google.com/group/mobicents-public/web/mobicents-sip-presence-service-guide

Looking forward to your feedback!!!

Mobicents/JBoss Communication Platform Team
------=_Part_90151_17092128.1218672367094-- --===============1798476354== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --===============1798476354==-- From simple-bounces@ietf.org Thu Aug 14 06:19:02 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 247D63A6DC5; Thu, 14 Aug 2008 06:19:02 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BCB83A6DC6 for ; Thu, 14 Aug 2008 06:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 HeycOX33F3+4 for ; Thu, 14 Aug 2008 06:18:59 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6B0543A6DB5 for ; Thu, 14 Aug 2008 06:18:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,210,1217808000"; d="scan'208";a="17483885" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Aug 2008 13:18:44 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7EDIiv8017148; Thu, 14 Aug 2008 09:18:44 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m7EDIicu015513; Thu, 14 Aug 2008 13:18:44 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Aug 2008 09:17:04 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Aug 2008 09:17:03 -0400 Message-ID: <48A43088.4010209@cisco.com> Date: Thu, 14 Aug 2008 09:18:00 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: JaekwonOH References: <005001c8f69b$54282520$cf1a590a@JKOH> <4C607BEA097DF048BEA625B974A36618730B56@306900ANEX2.global.avaya.com> <012301c8f84c$eeeb9a80$cf1a590a@JKOH> <489AE135.4050000@cisco.com> <00e201c8f921$4d33b350$cf1a590a@JKOH> <489C4001.6070303@cisco.com> <001c01c8fd9e$b1df7150$cf1a590a@JKOH> In-Reply-To: <001c01c8fd9e$b1df7150$cf1a590a@JKOH> X-OriginalArrivalTime: 14 Aug 2008 13:17:03.0936 (UTC) FILETIME=[0B1BC400:01C8FE10] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9150; t=1218719924; x=1219583924; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20How=20to=20show=20presentity 's=20relative=20service=20preference |Sender:=20 |To:=20JaekwonOH=20; bh=UXp7W0XgK4AcE37xlBt+G6pPE2uiX3NRDBioalMhH3w=; b=Fq+7uTdb+vrlB7xcmo/yBIEZ8s8rH31jH7y8dBTHs5p5s8e7AUCNJohLYk 9OsjbihkIBeMlY+yxz5PFFI5QPKradLqjK3TS0gwUF64nQtMKJZ4oUp+rZ1+ lvEvilHLF7; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Simple WG Subject: Re: [Simple] How to show presentity's relative service preference X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org JaekwonOH wrote: > Hi Paul, > = >> What would lead you to think you can't have as many unique addresses as = >> you want? > = > SIP applications for a registered user (i.e., presentity), such as voip, = ptt, and im. They can share the user's SIP AOR as contact address, and be d= ifferentiated each other with different feature tags. = You didn't answer my question. Unique addresses are cheap. Why not use = as many as you need? Also, this subject was discussed at length some years ago. The question is what you expect the caller to do to establish contact = with an advertised service of a presentity. The straightforward thing is = to simply expect the caller to send an INVITE (or whatever) to the = contact address listed for the service. If there is more than one = mutually exclusive services that share a contact address, then this is = not likely to get the intended result. Alternatively, you may expect the caller to add other signaling elements = to the request, over and above the contact address, to indicate what = service(s)/feature(s)/capabilities it desires of the target when the = contact address doesn't uniquely identify that. The problem with the latter is that the caller must know that it is = expected to do this, and also know *what* additional signaling elements = to add to achieve this. Its especially problematic if what needs to be = added varies from one callee to another for the same capability. A compromise here would be for the registered contact to have embedded = sip headers. When this contact is used, these headers would be added to = the request. But that is a feature that isn't universally (or often) = implemented. Ensuring that every "service" has a unique contact address is certainly = likely to maximize the chance of establishing the desired type of = session. This is easy and cheap for a UA to do if it is implementing its = own services. If it is depending on an upstream app server to implement = the services then things get more complex, but I think this approach can = still work. Thanks, Paul > Thanks & regards, > Jaekwon OH > = > ----- Original Message ----- = > From: "Paul Kyzivat" > To: "JaekwonOH" > Cc: "Smyth, Colm (Colm)" ; "Simple WG" > Sent: Friday, August 08, 2008 9:45 PM > Subject: Re: [Simple] How to show presentity's relative service preference > = > = >> >> JaekwonOH wrote: >>> Thanks for comment. >>> >>>> Only if it wants them to. It certainly may use a separate contact uri = >>>> for each application. (They probably have the same address and are = >>>> distinguished by the user part, or port.) Its the responsibility of th= e = >>>> application to put in enough uniqueness to get proper results. >>> I agree that if all each application can have unique contact address th= en there's no problem. >>> However, as I understand relevant RFCs incl. RFC4479, this seems not al= ways the case. = >> What would lead you to think you can't have as many unique addresses as = >> you want? >> >>> So, when the contact address is not unique over different applications,= it is questionable whether the priority attribute can be still meaningful = to show presentity's relative service preference... >>> >>> Thanks & regards, >>> Jaekwon OH >>> >>> ----- Original Message ----- = >>> From: "Paul Kyzivat" >>> To: "JaekwonOH" >>> Cc: "Simple WG" ; "Smyth, Colm (Colm)" >>> Sent: Thursday, August 07, 2008 8:49 PM >>> Subject: Re: [Simple] How to show presentity's relative service prefere= nce >>> >>> >>>> JaekwonOH wrote: >>>>> Hi, >>>>> = >>>>> Thanks for response. >>>>> Even when the device contact URI registered for an AOR is used for = >>>>> tuple's contact address, the uniqueness of the contact address for a = >>>>> tupe seems not guaranteed. For example, a device may run multiple SIP = >>>>> applications, then tuples for each of those would contain the same UR= I. >>>> Only if it wants them to. It certainly may use a separate contact uri = >>>> for each application. (They probably have the same address and are = >>>> distinguished by the user part, or port.) Its the responsibility of th= e = >>>> application to put in enough uniqueness to get proper results. >>>> >>>> Paul >>>> >>>>> This aspect has already been clarified in RFC 4479 (see the following = >>>>> excerption). >>>>> Therefore, IMHO, the uniquness of contact address for each tuple seem = >>>>> not guaranteed, so the use of 'priority' attribute of in = >>>>> is not enogh to show the presenity's relative service prefere= nce. >>>>> = >>>>> From RFC 4479 section 3.3.2 reach information, >>>>> = >>>>> Even for services reachable over a communications network, the URI >>>>> alone may not be sufficient. For example, two applications may be >>>>> running within a cellular telephone, both of which are reachable >>>>> through the user=92s SIP Address of Record. However, one application >>>>> is launched when the INVITE request contains a body of a particular >>>>> type, and the other is launched for other body types. As another >>>>> example, a service may provide complex application logic that >>>>> operates correctly only when contacted from matching application >>>>> software. In such a case, even though the communications between >>>>> instances utilizes a standard protocol (such as SIP), the user >>>>> experience will not be correct unless the applications are matched. >>>>> When the URI is not sufficient, additional attributes of the service >>>>> can be present that define the instructions on how the service is to >>>>> be reached. These attributes must be understood for the service to >>>>> be utilized. If a watcher receives a presence document containing >>>>> reach information it does not understand, it should discard the >>>>> service information. >>>>> = >>>>> = >>>>> Thanks & regards, >>>>> Jaekwon OH >>>>> ----- Original Message ----- >>>>> >>>>> *From:* Smyth, Colm (Colm) >>>>> *To:* Simple WG >>>>> *Sent:* Wednesday, August 06, 2008 1:23 AM >>>>> *Subject:* Re: [Simple] How to show presentity's relative service >>>>> preference >>>>> >>>>> I suggest that if there are multiple contact addresses for a sing= le >>>>> AOR, the contact element of each related tuple in PIDF should >>>>> reflect a unique contact address for this AOR, not the ambiguous = AOR >>>>> itself. >>>>> = >>>>> A unique address is useful, not just as an identifier for the >>>>> tuple's source, but to reach the address; then, the priority >>>>> attribute has a meaningful scope. >>>>> = >>>>> Colm Smyth >>>>> Lead/Architect - Intelligent Presence Server (IPS) | Unified >>>>> Communications >>>>> *AVAYA* | smythc@avaya.com | +353 1 656 >>>>> 7843 (x37843) >>>>> = >>>>> >>>>> -----------------------------------------------------------------= ------- >>>>> *From:* simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] = *On >>>>> Behalf Of *JaekwonOH >>>>> *Sent:* 05 August 2008 02:34 >>>>> *To:* Simple WG >>>>> *Subject:* [Simple] How to show presentity's relative service pre= ference >>>>> >>>>> Hi all, >>>>> = >>>>> I'm wondering how a presentity can show his perferred services in >>>>> presence. >>>>> A possibility seems to use the 'priority' attribute of >>>>> element for this purpose. >>>>> However, RFC 3863 defines that the 'priority' attribute shows the >>>>> presentity's different preference over *contact address*, so it is >>>>> not clear whether this is good enough to show the presentity's >>>>> relative service preference. >>>>> For example, when there are multiple SIP services that share the >>>>> presentity's AOR as contact address, then how the different >>>>> 'priority' attribute value for the same contact address should be >>>>> interpreted? >>>>> IMHO, this happens because a service cannot be represented only w= ith >>>>> the contact information. Rather, as noted in RFC 4476, a service = is >>>>> identified by the "reach information", which is a set of presence >>>>> information to reach the service including the contact address. >>>>> If this is the case, what should we do? >>>>> Thanks & regards, >>>>> = >>>>> Jaekwon OH >>>>> >>>>> -----------------------------------------------------------------= ------- >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>> ---------------------------------------------------------------------= --- >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 20 14:56:24 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C1F13A686A; Wed, 20 Aug 2008 14:56:24 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B102B3A686A for ; Wed, 20 Aug 2008 14:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 1TuiAJyOiL2r for ; Wed, 20 Aug 2008 14:56:10 -0700 (PDT) Received: from estacado.net (unknown [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 8F1773A6816 for ; Wed, 20 Aug 2008 14:56:09 -0700 (PDT) Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m7KLuDXx067240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Aug 2008 16:56:14 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: manju kori In-Reply-To: <491167.21986.qm@web65401.mail.ac4.yahoo.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 20 Aug 2008 16:56:13 -0500 References: <491167.21986.qm@web65401.mail.ac4.yahoo.com> X-Mailer: Apple Mail (2.928.1) Cc: simple@ietf.org Subject: Re: [Simple] Doubt in aborting the MSRP message transfer X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Aug 13, 2008, at 7:04 AM, manju kori wrote: > Hello All, > > I have a doubt in Abort procedure used in MSRP Protocol. > > Scenario is, I have active message (ex: file/buffer) transfer going > on, and the message receiver aborted the transfer, then according to > RFC, it should send response 413 to the sender. > > My question is, > Does Receiver endpoint need to generate new transaction id for this > 413 response? Or it need to get the trasaction id from previous > chunk received for that perticular message? The transaction ID for a response is always copied from a received (or in process) chunk. Generally you if you need to send a 413 response, you are either in the process of receiving a chunk, or you receive a new chunk after the decision to abort. (That is, there is not much point in aborting a transfer that is already complete.) You would take the transaction ID from that chunk. > > Thanks in advance > -Manju > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 27 08:46:46 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76E33A6C76; Wed, 27 Aug 2008 08:46:46 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80ED63A6C76 for ; Wed, 27 Aug 2008 08:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.297 X-Spam-Level: * X-Spam-Status: No, score=1.297 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_RFC_BOGUSMX=1.482] 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 1UjEP3MV+c3I for ; Wed, 27 Aug 2008 08:46:40 -0700 (PDT) Received: from node05.dns-hosting.info (node05.dns-hosting.info [85.17.186.5]) by core3.amsl.com (Postfix) with ESMTP id BEB0B3A6AD5 for ; Wed, 27 Aug 2008 08:46:38 -0700 (PDT) Received: from mit.xs4all.nl ([80.101.96.20] helo=[192.168.1.6]) by node05.dns-hosting.info with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.68) (envelope-from ) id 1KYNBP-00011p-3D for simple@ietf.org; Wed, 27 Aug 2008 17:43:44 +0200 Message-Id: From: Adrian Georgescu To: simple@ietf.org Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 27 Aug 2008 17:46:16 +0200 X-Mailer: Apple Mail (2.928.1) X-SA-Exim-Connect-IP: 80.101.96.20 X-SA-Exim-Mail-From: ag@ag-projects.com X-SA-Exim-Version: 4.2.1 (built Tue, 21 Aug 2007 23:39:36 +0000) X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info) Subject: Re: [Simple] draft minutes for SIMPLE at IETF72 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hello, 1. Noted by another vendor that all current requests are for B2BUA or comedia relays, and not MSRP relays. Comment: To clarify (the above was aimed at me) the RFPs I received required transparent signalling and the MSRP relay was required only for the purpose of NAT traversal. The goal was to allow end-points to talk to each other and preserve the original end-point session and signalling information. So the requirements wanted to have no B2BUAs in the path just a transparent SIP Proxy. So we have conflicting stories here. 2. Question: What has changed since the arguments that led us to develo MSRP relays? JDR thinks that the initial model of shared TCP connections between relays/carriers/enterprises has not developed, so people care less about it. We should not be afraid to learn from industry experience. Comment: During implementation of the MSRPRelay we have discarded the idea of sharing TCP connections for multiple MSRP session because it was not possible to do end-to-end congestion control for different types of MSRP traffic at the same time. This makes the relay less scalable but I do not believe is that relevant anymore nowadays. One machine can never handle the traffic anyway and an architecture where you have more machines working tother is more practical then optimizing session in a single box. The standards do not have to be changed to accomodate multiple relays to work together like one. 3. Noted that the need for relays has diminished with the increased TCPcapacity of modern OS. Comment: The above statement does not help traverse NATs so is not a valid argument. Regards, Adrian >>> Please review and provide any corrections and comments as soon as you can. Thanks! RjS ======================= Minutes - SIMPLE - IETF72 _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 27 09:59:31 2008 Return-Path: X-Original-To: simple-archive@megatron.ietf.org Delivered-To: ietfarch-simple-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 016C33A6A7C; Wed, 27 Aug 2008 09:59:31 -0700 (PDT) X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F31B13A69E9 for ; Wed, 27 Aug 2008 09:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.687 X-Spam-Level: X-Spam-Status: No, score=-5.687 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 ZV3SxTxqB5+t for ; Wed, 27 Aug 2008 09:59:29 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 132683A694C for ; Wed, 27 Aug 2008 09:59:29 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 59CF92037B for ; Wed, 27 Aug 2008 18:58:36 +0200 (CEST) X-AuditID: c1b4fb3e-aa688bb000007a96-75-48b587bc903d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 40589201B9 for ; Wed, 27 Aug 2008 18:58:36 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 18:58:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 18:57:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSRP-ACM: Comedia stand-alone? Thread-Index: Acj2+xxbS/+Ew9mmTDymF8OZqDz5hARauAqd References: From: "Christer Holmberg" To: "Christer Holmberg" , X-OriginalArrivalTime: 27 Aug 2008 16:58:36.0078 (UTC) FILETIME=[25366CE0:01C90866] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] MSRP-ACM: Comedia stand-alone? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Any opinions on this issue? Quite many had an opinion in Dublin :) Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: simple-bounces@ietf.org puolesta: Christer Holmberg L=E4hetetty: ti 5.8.2008 14:59 Vastaanottaja: simple@ietf.org Aihe: [Simple] MSRP-ACM: Comedia stand-alone? = Hi, As agreed in Dublin, we are planning to set up a phone meeting regarding the alternative connection model for MSRP. But, before that I'd like to bring up one issues we need to address: should one be allowed to use comedia together with the current MSRP routing model, or will comedia and SDP c/m line routing go together? If comedia and c/m line routing go together we won't need the msrp-acm attribute defined in the draft, because the comedia attributes will act as indicators. Regards, Christer _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple