From mailman-bounces@ietf.org Wed Sep 1 10:00:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07134 for ; Wed, 1 Sep 2004 09:35:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2TJ7-0004bQ-UM for simple-archive@ietf.org; Wed, 01 Sep 2004 07:29:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2RIW-0000kD-H3 for simple-archive@ietf.org; Wed, 01 Sep 2004 05:20:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: simple-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Sep 2004 05:05:07 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for simple-archive@ietf.org: List Password // URL ---- -------- simple@ietf.org onahda https://www1.ietf.org/mailman/options/simple/simple-archive%40ietf.org From simple-bounces@ietf.org Wed Sep 1 16:30:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29322; Wed, 1 Sep 2004 16:30:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2bmH-0005oM-4s; Wed, 01 Sep 2004 16:32:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2be7-0000gb-0P; Wed, 01 Sep 2004 16:23:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2b7E-0000zL-FC for simple@megatron.ietf.org; Wed, 01 Sep 2004 15:49:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26562 for ; Wed, 1 Sep 2004 15:49:51 -0400 (EDT) Received: from [64.69.76.4] (helo=dns1.xten.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2b9B-0002II-Tt for simple@ietf.org; Wed, 01 Sep 2004 15:52:13 -0400 Received: from [24.1.66.77] by dns1.xten.net (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.5.3)); Wed, 1 Sep 2004 12:49:26 -0700 In-Reply-To: <1092924161.1986.7.camel@localhost.localdomain> References: <1092924161.1986.7.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Simple] Minutes/proceedings - IETF60 Date: Wed, 1 Sep 2004 14:47:14 -0500 To: Robert Sparks X-Mailer: Apple Mail (2.619) X-ArGoMail-Authenticated: robert@xten.com X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Folks, I received no comments on these draft minutes. I'm submitting them as-is to the proceedings today. Thanks, RjS On Aug 19, 2004, at 9:02 AM, Robert Sparks wrote: > The slides from San Diego are on softarmor at > http://www.softarmor.com/simple/meets/ietf60/slides/ > and in the draft proceedings at > http://www.ietf.org/proceedings/04aug/index.html > > Draft minutes are attached. > > Please provide feedback/correction no later than 8/31. > > Thanks, > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 1 16:36:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29823; Wed, 1 Sep 2004 16:36:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2bsO-0006H3-9f; Wed, 01 Sep 2004 16:38:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2bep-0001fI-Dj; Wed, 01 Sep 2004 16:24:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2bFd-0006MQ-2u for simple@megatron.ietf.org; Wed, 01 Sep 2004 15:58:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27040 for ; Wed, 1 Sep 2004 15:58:34 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2bHs-00031k-LR for simple@ietf.org; Wed, 01 Sep 2004 16:00:56 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Wed, 1 Sep 2004 12:57:38 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Sep 2004 12:59:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Contributor ID Date: Wed, 1 Sep 2004 12:58:13 -0700 Message-ID: Thread-Topic: [Simple] MSRP: Contributor ID Thread-Index: AcSPtQRpdO45pro2TMyvmHWzlNTC1QAmnAJQ From: "Orit Levin" To: "Adam Roach" , X-OriginalArrivalTime: 01 Sep 2004 19:59:11.0010 (UTC) FILETIME=[25E1D820:01C4905E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable A clarification to the clarification. We are not debating "a redundant mechanism for doing the same thing". I don't think that there has been a doubt that MSRP entities MUST support CPIM and MUST be able to receive and process it. The ongoing debate is whether - the CPIM technique can work for both centralized conferencing and peer-to-peer security/privacy in the same time OR - MSRP needs to define additional means for conferencing support (in order to be able to use CPIM for its original purpose!) Orit. =20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Tuesday, August 31, 2004 4:39 PM > To: hisham.khartabil@nokia.com > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP: Contributor ID >=20 > hisham.khartabil@nokia.com wrote: >=20 > >- Rohan will write up a separate internet draft describing=20 > the header approach with its security considerations. > > > >- Robert will kick off an internet draft describing the body=20 > approach (be it CPIM or something else) and its security=20 > considerations. > > >=20 > Just to be clear: Section 4.1.1 of RFC 2779 absolutely,=20 > unambiguously, and without recourse for appeal binds SIMPLE=20 > to support CPIM in MSRP.=20 > Section 4.1.2 similarly requires us to be able to identify=20 > the sender.=20 > These mechansims, simply put, must be in MRSP, or it dies in=20 > IESG review. >=20 > Full stop. >=20 > So, I want to clear up any misunderstanding that this might=20 > be an either-or decision -- an impression Hisham's note may=20 > have given some particpants. >=20 > The support of CPIM _will_ be part of MSRP, it _will_ contain=20 > mechanisms for identifying the sender, and there's not a=20 > thing any member of this working group can do about it. >=20 > At this point, we're just debating whether there will be a=20 > redundant mechanism for doing the same thing. >=20 > /a >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 2 09:14:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01362; Thu, 2 Sep 2004 09:14:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2rSK-0002Rp-M8; Thu, 02 Sep 2004 09:16:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2rIV-0000ya-2E; Thu, 02 Sep 2004 09:06:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0m8h-0006MR-Mr; Fri, 27 Aug 2004 15:11:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26282; Fri, 27 Aug 2004 15:11:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0m9u-0000IL-4y; Fri, 27 Aug 2004 15:13:10 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1C0lyW-0007Kp-SI; Fri, 27 Aug 2004 15:01:24 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 27 Aug 2004 15:01:24 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Thu, 02 Sep 2004 09:06:37 -0400 Cc: simple chair , Internet Architecture Board , simple mailing list , RFC Editor Subject: [Simple] Protocol Action: 'Indication of Message Composition for Instant Messaging' to Proposed Standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 The IESG has approved the following document: - 'Indication of Message Composition for Instant Messaging ' as a Proposed Standard This document is the product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group. The IESG contact persons are Ted Hardie and Scott Hollenbeck. Technical Summary This document extends the SIMPLE IM system, defining a new status message content type and XML namespace. These will be used to relay information during an IM conversation that indicates that one party is composing a message and conveys information about the information being composed The status message can indicate the composition of a message of any type, including text, voice or video. Working Group Summary The working group came to consensus on this document, and this feature is widely implemented in existing IM systems, so its utility is well understood. Protocol Quality This document was reviewed for the IESG by Ted Hardie. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 2 09:15:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01490; Thu, 2 Sep 2004 09:15:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2rTe-0002fS-2i; Thu, 02 Sep 2004 09:18:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2rIV-0000yf-Fj; Thu, 02 Sep 2004 09:06:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2AtX-0007dj-On; Tue, 31 Aug 2004 11:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26676; Tue, 31 Aug 2004 11:50:01 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2AvY-0006Kg-3w; Tue, 31 Aug 2004 11:52:08 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i7VFnLJ15999; Tue, 31 Aug 2004 08:49:21 -0700 (PDT) Message-Id: <200408311549.i7VFnLJ15999@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 31 Aug 2004 08:49:21 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 X-Mailman-Approved-At: Thu, 02 Sep 2004 09:06:37 -0400 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 3856 on A Presence Event Package for the Session Initiation Protocol (SIP) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3856 Title: A Presence Event Package for the Session Initiation Protocol (SIP) Author(s): J. Rosenberg Status: Standards Track Date: August 2004 Mailbox: jdrosen@dynamicsoft.com Pages: 27 Characters: 62956 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-presence-10.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3856.txt This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence Profile (CPP) framework. This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040831084723.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3856 --OtherAccess Content-Type: Message/External-body; name="rfc3856.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040831084723.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Thu Sep 2 09:16:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01560; Thu, 2 Sep 2004 09:16:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2rUj-0002gZ-2h; Thu, 02 Sep 2004 09:19:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2rIV-0000yk-W3; Thu, 02 Sep 2004 09:06:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Axt-0002fX-4i; Tue, 31 Aug 2004 11:54:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27190; Tue, 31 Aug 2004 11:54:30 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Azt-0006Qv-CQ; Tue, 31 Aug 2004 11:56:37 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i7VFpVJ16624; Tue, 31 Aug 2004 08:51:31 -0700 (PDT) Message-Id: <200408311551.i7VFpVJ16624@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 31 Aug 2004 08:51:31 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 X-Mailman-Approved-At: Thu, 02 Sep 2004 09:06:37 -0400 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 3857 on A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3857 Title: A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP) Author(s): J. Rosenberg Status: Standards Track Date: August 2004 Mailbox: jdrosen@dynamicsoft.com Pages: 20 Characters: 46221 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-winfo-package-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3857.txt This document defines the watcher information template-package for the Session Initiation Protocol (SIP) event framework. Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. This event package is a template-package because it can be applied to any event package, including itself. This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040831084933.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3857 --OtherAccess Content-Type: Message/External-body; name="rfc3857.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040831084933.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Thu Sep 2 09:17:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01609; Thu, 2 Sep 2004 09:17:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2rVO-0002hN-Us; Thu, 02 Sep 2004 09:19:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2rIW-0000yp-IK; Thu, 02 Sep 2004 09:06:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Ayu-0002l9-FS; Tue, 31 Aug 2004 11:55:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27266; Tue, 31 Aug 2004 11:55:34 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2B0u-0006TW-S2; Tue, 31 Aug 2004 11:57:41 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i7VFrRJ16914; Tue, 31 Aug 2004 08:53:27 -0700 (PDT) Message-Id: <200408311553.i7VFrRJ16914@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 31 Aug 2004 08:53:27 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f X-Mailman-Approved-At: Thu, 02 Sep 2004 09:06:37 -0400 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 3858 on An Extensible Markup Language (XML) Based Format for Watcher Information X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3858 Title: An Extensible Markup Language (XML) Based Format for Watcher Information Author(s): J. Rosenberg Status: Standards Track Date: August 2004 Mailbox: jdrosen@dynamicsoft.com Pages: 13 Characters: 26416 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-winfo-format-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3858.txt Watchers are defined as entities that request (i.e., subscribe to) information about a resource. There is fairly complex state associated with these subscriptions. The union of the state for all subscriptions to a particular resource is called the watcher information for that resource. This state is dynamic, changing as subscribers come and go. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular resource. In order to enable this, a format is needed to describe the state of watchers on a resource. This specification describes an Extensible Markup Language (XML) document format for such state. This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040831085157.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3858 --OtherAccess Content-Type: Message/External-body; name="rfc3858.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040831085157.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Thu Sep 2 17:09:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11793; Thu, 2 Sep 2004 17:09:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2yrc-0000Gy-G2; Thu, 02 Sep 2004 17:11:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2yZx-0006vP-RA; Thu, 02 Sep 2004 16:53:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2yBT-000851-LH for simple@megatron.ietf.org; Thu, 02 Sep 2004 16:27:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05408 for ; Thu, 2 Sep 2004 16:27:49 -0400 (EDT) Received: from [64.69.76.4] (helo=dns1.xten.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2yDf-000488-S3 for simple@ietf.org; Thu, 02 Sep 2004 16:30:24 -0400 Received: from [24.1.66.77] by dns1.xten.net (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.5.3)); Thu, 2 Sep 2004 13:27:48 -0700 In-Reply-To: <20040831150220.PQBX1729.mm-ismta3.bizmailsrvcs.net@THANOSDIACAKIS3> References: <20040831150220.PQBX1729.mm-ismta3.bizmailsrvcs.net@THANOSDIACAKIS3> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3F39E724-FD1E-11D8-9BF7-000D93326732@xten.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Thu, 2 Sep 2004 15:25:35 -0500 To: simple@ietf.org X-Mailer: Apple Mail (2.619) X-ArGoMail-Authenticated: robert@xten.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Ted Hardie Subject: [Simple] Partial Publish as WG item X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit OK - there appear to be several people willing to comment on this mechanism now and rough consensus to take it on as a working group item, with draft-lonnfors-simple-partial-publish-01 as a starting point. Those folks who have chimed in with explicit support and concerns: we will be calling on you to review and comment. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 7 08:08:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15889; Tue, 7 Sep 2004 08:08:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4ep8-0002pa-Gj; Tue, 07 Sep 2004 08:11:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4ehn-0002ET-U4; Tue, 07 Sep 2004 08:04:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4ee5-0001US-Ut for simple@megatron.ietf.org; Tue, 07 Sep 2004 08:00:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15114 for ; Tue, 7 Sep 2004 08:00:20 -0400 (EDT) Received: from ajou.ac.kr ([202.30.0.11] helo=madang.ajou.ac.kr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4ehV-0002bv-EW for simple@ietf.org; Tue, 07 Sep 2004 08:03:55 -0400 Received: from ajoudayhakyu ([202.30.16.134]) by madang.ajou.ac.kr (8.12.10-H/8.12.6) with SMTP id i87BvMMo025525 for ; Tue, 7 Sep 2004 20:57:22 +0900 (KST) Message-ID: <034601c494d2$982a0470$86101eca@ajoudayhakyu> From: "Faisal Adeem Siddiqui" To: Date: Tue, 7 Sep 2004 21:02:48 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.5 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Simple] Regarding the SIP register messages in SIP for Networked Appliances X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============1395713300==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This is a multi-part message in MIME format. --===============1395713300== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0343_01C4951E.07F9DEB0" This is a multi-part message in MIME format. ------=_NextPart_000_0343_01C4951E.07F9DEB0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable I want to know why the To and From addresses are same in this (see = below) Register message ? Do we really need the "To" address ? Shouldn't = the "To" address be "registrar@home.net" ?=20 Please explain. REGISTER registrar@home.net To: [slp:/d=3Dalarmclock, r=3Dbedroom,u=3Dstanm]@ua.stan.home.net From: [slp:/d=3Dalarmclock, r=3Dbedroom,u=3Dstanm]@ua.stan.home.net=20 Content-type: application/ddp [Device Address] Thanks in advance. Faisal. ------=_NextPart_000_0343_01C4951E.07F9DEB0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
I want to know why the To and = From=20 addresses are same in this (see below) Register message ? Do we = really=20 need the "To" address ? Shouldn't the "To" address be "registrar@home.net" ? =
Please explain.
 
REGISTER registrar@home.net
To: [slp:/d=3Dalarmclock,=20 r=3Dbedroom,u=3Dstanm]@ua.stan.home.net
From: [slp:/d=3Dalarmclock,=20 r=3Dbedroom,u=3Dstanm]@ua.stan.home.net
Content-type:=20 application/ddp
[Device Address]
 
Thanks in = advance.
Faisal.
------=_NextPart_000_0343_01C4951E.07F9DEB0-- --===============1395713300== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1395713300==-- From simple-bounces@ietf.org Tue Sep 7 08:51:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18138; Tue, 7 Sep 2004 08:51:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4fUe-0003Qm-R8; Tue, 07 Sep 2004 08:54:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4fOV-0001rx-UP; Tue, 07 Sep 2004 08:48:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4fIb-000136-GS for simple@megatron.ietf.org; Tue, 07 Sep 2004 08:42:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17773 for ; Tue, 7 Sep 2004 08:42:11 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4fM1-0003Kj-MX for simple@ietf.org; Tue, 07 Sep 2004 08:45:47 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i87Cfq113644; Tue, 7 Sep 2004 15:41:52 +0300 (EET DST) X-Scanned: Tue, 7 Sep 2004 15:41:40 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i87CfeU4021136; Tue, 7 Sep 2004 15:41:40 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00H27pQe; Tue, 07 Sep 2004 15:41:39 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i87CfWY05261; Tue, 7 Sep 2004 15:41:33 +0300 (EET DST) Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 7 Sep 2004 15:41:32 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 7 Sep 2004 15:41:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Partial Publish as WG item Date: Tue, 7 Sep 2004 15:41:31 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B574@esebe056.ntc.nokia.com> Thread-Topic: [Simple] Partial Publish as WG item Thread-Index: AcSRMUz43sOTnlXfQACOWMwwDL5L1wDpiiLw To: , X-OriginalArrivalTime: 07 Sep 2004 12:41:32.0932 (UTC) FILETIME=[01539C40:01C494D8] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: hardie@qualcomm.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable We will be producing a new version of the Patrial Publish internet draft = as a WG item soon. Please review the current version and report any = issues you find. The draft can be found at: http://www.ietf.org/internet-drafts/draft-lonnfors-simple-partial-publish= -01.txt There is one open issue known to the authors, and that is the behaviour = at the server when there are XML errors. Regards, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Robert Sparks > Sent: 02.September.2004 23:26 > To: simple@ietf.org > Cc: Ted Hardie > Subject: [Simple] Partial Publish as WG item >=20 >=20 > OK - there appear to be several people willing to comment on this=20 > mechanism now and > rough consensus to take it on as a working group item, with > draft-lonnfors-simple-partial-publish-01 as a starting point. >=20 > Those folks who have chimed in with explicit support and concerns: we=20 > will be > calling on you to review and comment. >=20 > Thanks, >=20 > RjS >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 7 11:20:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29257; Tue, 7 Sep 2004 11:20:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4hou-0005sy-H1; Tue, 07 Sep 2004 11:23:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4hjT-0004Aa-Ga; Tue, 07 Sep 2004 11:18:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4hf6-0003Xo-RP for simple@megatron.ietf.org; Tue, 07 Sep 2004 11:13:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28842 for ; Tue, 7 Sep 2004 11:13:34 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4hiY-0005mf-6F for simple@ietf.org; Tue, 07 Sep 2004 11:17:11 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 07 Sep 2004 08:19:13 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i87F9q9N006042; Tue, 7 Sep 2004 08:09:53 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALJ01405; Tue, 7 Sep 2004 11:09:54 -0400 (EDT) Message-ID: <413DCF42.8020508@cisco.com> Date: Tue, 07 Sep 2004 11:09:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Faisal Adeem Siddiqui Subject: Re: [Simple] Regarding the SIP register messages in SIP for Networked Appliances References: <034601c494d2$982a0470$86101eca@ajoudayhakyu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Faisal Adeem Siddiqui wrote: > I want to know why the To and From addresses are same in this (see > below) Register message ? Do we really need the "To" address ? Shouldn't > the "To" address be "registrar@home.net " ? > Please explain. - The To-URI identifies the address of record that is to be modified by the registration. - The Request-URI identifies the registrar that is intended to process the registration. Often it is obtained by stripping the user part from the To-URI. But it is up the the UAC to do this, or otherwise determine what it is. - The From-URI identifies the Address of record of the UAC that is sending the REGISTER message. It is certainly a very common case for this to be the same as the To-URI, but it need not be the case. The technique of deriving the Request-URI is indeed odd and inconsistent with what is typically done for other sip messages. I believe it is just an artifact of the way that sip has evolved. But that is the way it is. Paul > REGISTER registrar@home.net > To: [slp:/d=alarmclock, r=bedroom,u=stanm]@ua.stan.home.net > From: [slp:/d=alarmclock, r=bedroom,u=stanm]@ua.stan.home.net > Content-type: application/ddp > [Device Address] > > Thanks in advance. > Faisal. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 7 14:33:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18760; Tue, 7 Sep 2004 14:33:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4kq7-0002sM-Le; Tue, 07 Sep 2004 14:37:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4kXZ-00082G-GI; Tue, 07 Sep 2004 14:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4kRb-00066I-7Q for simple@megatron.ietf.org; Tue, 07 Sep 2004 14:11:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16796 for ; Tue, 7 Sep 2004 14:11:49 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4kV4-0002IS-Tz for simple@ietf.org; Tue, 07 Sep 2004 14:15:27 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 07 Sep 2004 11:08:07 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i87I7c71014400; Tue, 7 Sep 2004 11:07:53 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALJ19035; Tue, 7 Sep 2004 14:06:48 -0400 (EDT) Message-ID: <413DF8B8.40809@cisco.com> Date: Tue, 07 Sep 2004 14:06:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin Subject: Re: [Simple] MSRP: Contributor ID References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Content-Transfer-Encoding: 7bit Sorry for delayed response - I've been on vacation, but am now back. Orit Levin wrote: > Paul, > The answer to "why" in each of the cases relates to the fact that > different cases belong to same architecture/possible deployment. Even > when you see a solution to one case - you are unintentionally missing > another unless you go through the exercise of defining the full > conferencing architecture. > > Instead, if we step back and try to look at the problem from the top, > CPIM is a simple means for peer-to-peer private communications with > non-trusted intermediates (e.g. GW, MCUs) potentially present in the > middle. Using CPIM for communications between users and the > intermediates themselves (and still being able to use CPIM for what it > had been designed for) without defining standard ubiquitous means for > distinguishing between the cases - is close to impossible. I'm still not convinced of why the recipient needs to be able to distinguish the cases. If a message is received, it could have: - no indication of source. All that is known is the identification of the other end of the signaling path. - it could have a single CPIM wrapper, unsigned, unencrypted, that identifies the source. The recipient doesn't know if this came from the actual sender, or from some intermediary. But does it matter? In either case it can't be authenticated. - it could have a single CPIM wrapper, signed by the actual sender. - it could have a single CPIM wrapper, signed by the mixer. - it could have two CPIM wrappers, one signed by the sender, one signed by the mixer. In all of the signed cases, what is the value in knowing via the protocol whether a signature came from the mixer or the sender? What is really important is who is signing and whether you can authenticate the signature. If you have multiple signatures that you trust, and the corresponding CPIM wrappers disagree about who the sender is, then you have to decide which to trust, or else just display them both. If you want to pick one, does it really help to know whether it came from the mixer or not? > On the RTP note, RTP is different from MSRP in many aspects: True. The analogy can only be stretched so far. > - RTP doesn't use CPIM and as a result doesn't have this problem to > start from :-) True. That of course wasn't the analogy I was considering. My point was that in a conference, the sender uses RTP/RTCP to talk to the mixer, including its capabilities for identifying the sender. Then the mixer uses RTP/RTCP to talk to the recipient, again using its capabilities for identifying the sender. There isn't one way for the sender to identify itself to the recipient and a different way for the mixer to represent its notion of the sender to the recipient. An analogous same state of affairs could be achieved using CPIM, if the mixer refuses to accept encrypted messages that it cannot decrypt. It could then receive messages, remove any incoming CPIM wrapper, then add and sign a CPIM wrapper for the recipient. > - SSRC is used as a stream identifier only. In the core RTP, there is no > multiplexing inside the UDP connection (which is 1-to-1 with the RTP > session). In MSRP, the from-path value is used as the part of the "MSRP > session identifier" for multiplexing inside a TCP tunnel. This is all true. But I don't see how it affects the discussion at hand. > - in addition to the RTP "mixer" mode being implemented today, RTP also > defines the "translator" mode - which is much closer to what happening > in IM conferencing case. It this mode, the original SSRC is PRESERVED by > translators (and the CSRC list is not created because it doesn't have > any meaning at all). This would be analogous to an MSRP mixer passing CPIM messages thru unmodified. Note that the description of translator mode in RFC 3550 mentions that when it is used the recipient can't tell that a translator is present. Note that RTP doesn't ever address the case where the sender doesn't provide CNAME info, or when it is wrong. Our case in MSRP of having the focus provide identification of the sender when the sender didn't provide that information is functionality not considered in RTP. > As it was stated earlier, voice and video > conferencing vendors got away with it only because the user can guess > the source by his/her voice or video. This doesn't work for IM unless an > advanced conferencing protocol (e.g. XCON) is being used by ALL > participants. Agreed that it is more important to receive sender identification with MSRP than it is with RTP. But then we are free to work out what the extended needs are. Paul > Orit. > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Thursday, August 26, 2004 12:00 PM >>To: Orit Levin >>Cc: Ben Campbell; Adam Roach; Alan Johnston; simple@ietf.org >>Subject: Re: [Simple] MSRP: Contributor ID >> >> >> >>Orit Levin wrote: >> >>> >>> >>>>If >>>>the message already had a cpim wrapper, then the focus >>> >>could choose to >> >>>>leave it alone, or put it inside yet another wrapper. >>>>(You can have nested cpim wrappers.) >>>> >>> >>>To accommodate the end-to-end encrypted CPIM, it will need to be >>>something like: >>>If the message already had a cpim wrapper and the destination is >>>conference-aware, then the focus puts it inside yet another clear >>>wrapper (that is in order to provide mapping to conferencing >>>extensions). >>>If the message already had a cpim wrapper and the destination is >>>conference-unaware (e.g. doesn't use XCON) leave it alone >> >>(that is in >> >>>order to not confuse the receiving client with conferencing >>>information vs. peer-to-peer information). >> >> > >> >>>This is VERY DIFFERENT from the existing today conferencing >>>architecture where the focus logic is NOT dependant on the >>>participant's ability to understand or actively support >> >>conferencing extensions and protocols. >> >>I don't understand why you are splitting out different >>behaviors for conference aware and unaware participants. >> >>If the focus wants to ensure that messages are properly >>identified as to source, then it will either have to add a >>CPIM wrapper, or else inspect and approve one that is already >>present. If the message is encrypted e2e so that the focus >>can't decrypt, then it doesn't matter whether the encrypted >>body is CPIM or not. Either way the focus will have to wrap >>the encrypted body in a new CPIM wrapper. >> >>It can only avoid this if it doesn't feel it is necessary to >>identify the message sender. It will be up to the conference >>arch to decide about that. Maybe it will depend on whether >>the recipient is conference aware, maybe not. >> >> >>>Yet "MY MAJOR PROBLEM" with using CPIM wrapper for >> >>conferencing/focus >> >>>can be summarised as following: >>>There is no (well-defined simple) way in the CPIM header to >>>distinguish whether a particular CPIM is being used for >> >>intermediate >> >>>(e.g. focus, >>>GW) vs. for peer-to-peer needs. A user may have very >> >>different privacy >> >>>policies regarding each. In the case of conference-unaware >> >>user - the >> >>>UA will not even have the ability to distinguish between >> >>the two cases. >> >>Why should there be? there isn't any way to do this for >>RTP/RTCP. There isn't any ability to have both kinds. And it >>is up to the mixer whether it preserves the IDs provided by >>the sender or puts in artificial ones. >>The recipient can't tell which is the case. >> >> >>>Which identity will the user put in the requested CPIM header? The >>>private (for peer-to-peer) or the public for the focus use? How the >>>receiving participant (which can be conference unaware as >> >>well) will >> >>>undertsand what kind of identity he is looking at? >> >>If there are multiple unsigned and unencrypted identities, >>then the recipient should probably display them all, or maybe >>none of them if it is untrusting. If some or all of the >>identities are signed, then it could choose to only display >>ones signed by somebody it trusts. >> >> Paul >> >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 8 10:12:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13935; Wed, 8 Sep 2004 10:12:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C53Et-0001L5-1F; Wed, 08 Sep 2004 10:15:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C532Z-0008Hf-Va; Wed, 08 Sep 2004 10:03:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C531o-0007Rl-6s for simple@megatron.ietf.org; Wed, 08 Sep 2004 10:02:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12767 for ; Wed, 8 Sep 2004 10:02:25 -0400 (EDT) Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C535O-00019l-AG for simple@ietf.org; Wed, 08 Sep 2004 10:06:14 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i88E1po1005566 for ; Wed, 8 Sep 2004 16:01:52 +0200 Received: from bruc100e.sbs.be (bruc100e.sbs.be [193.210.175.22]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i88E1pYu029119 for ; Wed, 8 Sep 2004 16:01:51 +0200 Received: by bruc100e.sbs.be with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Sep 2004 16:01:07 +0200 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195692173@hrtades7.atea.be> From: Goeman Stefan To: "'simple@ietf.org'" Subject: [Simple] Device priority Date: Wed, 8 Sep 2004 16:01:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============1002109543==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1002109543== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C495AC.615167D8" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C495AC.615167D8 Content-Type: text/plain Hello All, I have a small question. Suppose I have two devices, a laptop and a mobile phone with the same communication means ( they use same communication addresses). However, if both devices are active (and registered), I would like to receive IM on my laptop, and not on my phone. Is there a way to express to express the priority of the laptop over the mobile phone for receiving IMs? I do not (immediately) find this in the relevant RFC and IDs. The way I understand the format of the presence document (RFC3863) is that it groups a number of communication addresses (contact means + contact address), and these communication addresses are decoupled from the devices or user agents (which is not a bad idea I think). Can someone enlighten my here? Thanks in advance! Greetings, Stefan Goeman ------_=_NextPart_001_01C495AC.615167D8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable [Simple] Device priority

Hello All,

I have a small question.
Suppose I have two devices, a laptop = and a mobile phone with the same communication means ( they use same = communication addresses). However, if both devices are active (and = registered), I would like to receive IM on my laptop, and not on my = phone.

Is there a way to express to express = the priority of the laptop over the mobile phone for receiving IMs? I = do not (immediately) find this in the relevant RFC and IDs.

The way I understand the format of the = presence document (RFC3863) is that it groups a number of communication = addresses (contact means + contact address), and these communication = addresses are decoupled from the devices or user agents (which is not a = bad idea I think).

 
Can someone enlighten my here?
Thanks in advance!

Greetings,

Stefan = Goeman

------_=_NextPart_001_01C495AC.615167D8-- --===============1002109543== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1002109543==-- From simple-bounces@ietf.org Wed Sep 8 11:41:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22094; Wed, 8 Sep 2004 11:41:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C54dZ-0003Bp-SS; Wed, 08 Sep 2004 11:45:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C54R9-0007HR-An; Wed, 08 Sep 2004 11:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C54HD-0004lB-82 for simple@megatron.ietf.org; Wed, 08 Sep 2004 11:22:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20176 for ; Wed, 8 Sep 2004 11:22:20 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C54Kj-0002fo-Jb for simple@ietf.org; Wed, 08 Sep 2004 11:26:11 -0400 Received: from [192.168.1.20] ([64.114.198.10]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i88FM0Ka039694 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 8 Sep 2004 10:22:04 -0500 (CDT) (envelope-from RjS@xten.com) Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Wed, 8 Sep 2004 10:20:58 -0500 To: simple@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.2 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Content-Transfer-Encoding: 7bit Cc: Ted Hardie , hartmans@mit.edu Subject: [Simple] Security Review of draft-ietf-simple-message-sessions-07 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Content-Transfer-Encoding: 7bit Folks: At Ted's request, Sam Hartman performed a security review of the MSRP base specification. Sam's identified some things we need to do, and several things we need to talk about. The chairs, our technical advisor, or the editors of these drafts will be sending messages to the list responding to these points individually over the next few days, either with proposed text or starting a discussion on the topic. Please read this carefully and send your comments to the list. Thanks, RjS Begin forwarded message: >> This document reviews draft-ietf-simple-message-sessions-07.txt. That >> document specifies the MSRP protocol. >> >> Protocol Overview >> >> The MSRP protocol is a deceptively simple protocol for transporting >> messages in an instant messaging session. It provides two operations: >> a send request and a report request. Each request can generate a >> response. Each endpoint is defined by a MSRP URL. The URL contains >> the typical host and port, as well as a resource that identifies the >> specific destination of a message. For example if Alice and Bob are >> talking, they will both have MSRP URLs corresponding to their >> identities. MSRP specifies the optional use of TLS for transport >> level protection. >> >> However the security picture is actually a lot more complicated. >> First, the knowledge of the MSRP URL serves as authentication and >> authorization information. Since clients do not typically have TLS >> certificates, a server knows it is talking to the right party based on >> the URL that party sends to and possibly based on the response URL >> listed in the message. The URLs are used for authorization in that >> layers above MSRP deal with preventing spam and so it is important >> that only parties authorized to send messages have the MSRP URL. So >> MSRP URLs need to be chosen with a strong random component and if >> message integrity is desired, they need to be >> transported with confidentiality. >> SIP, the layer above MSRP is responsible for mapping SIP or CPIM URLs >> into MSRP URLs to set up a message session. This mapping is security >> critical because users are probably going to add SIP or CPIM URLs to >> their contact lists. So, to securely establish a connection, the >> combination of SIP and MSRP must securely map the user-entered URL to >> an MSRP URL. >> >> MSRP also involves S/MIME and CPIM identities. If S/MIME is used to >> get end-to-end encryption then the names of the chosen certificates >> must be verified. If message/cpim entities are sent, then the from >> and to fields in these messages must be matched. Typically the cpim >> identities will be instant inbox URLs although perhaps they could also >> be SIP URLs in some cases. >> >> One final identity is important for MSRP security. The MSRP >> specification requires that if TLS is used, the server certificate be >> for the hostname in the destination MSRP URL. This requirement for >> the TLS identity has important security implications. >> >> >> Security Requirements >> >> The draft does not specify a set of security requirements. IT seems >> reasonable to refer back to RFC 2779 for security requirements for >> this protocol. >> >> I explicitly choose to distinguish confidentiality protection at the >> transport layer from end-to-end confidentiality/integrity protection. >> RFC 2779 doesn't quite explicitly make this distinction, but it does >> require both integrity protection and support for digital signatures. >> This distinction seems reasonable for several reasons. First, other >> IM protocols including XMPP and APEX support both levels of >> protection. We've found with email that end-to-end encryption and >> transport level encryption are both useful; it seems likely that we >> will see the same thing with IM. >> >> I also introduce the concept of parties sharing a deployed >> authentication infrastructure. Ideally, we'd have some authentication >> infrastructure we could use to exchange key material with anyone on >> the Internet. In practice, we do not yet have this level of security >> integration. However we should try to provide security in >> environments where we can do so. Note that it is not acceptable to >> force people to deploy a new authentication infrastructure for your >> protocol if they already have an adequate infrastructure for some >> other purpose. If you can work within that infrastructure, then you >> significantly decrease deployment costs of making your protocol >> secure. >> >> 1) In order to provide integrity protection, the protocol must >> describe how identifiers entered by the user are securely mapped to >> identifiers used in the protocol. The protocol must describe >> necessary verifications of these mappings that recipients of messages >> need to perform in order to make sure they all refer to the same >> principal. >> >> 2) When two parties share an appropriate authentication >> infrastructure,then the protocol will provide a way for them to get >> hop-by-hop confidentiality and integrity. >> >> 3) When two parties share an appropriate authentication >> infrastructure, then the protocol will provide a mechanism for >> end-to-end confidentiality and integrity. >> >> 4) Even when no authentication infrastructure is shared, the protocol >> will provide protection against passive attacks. >> >> Security Evaluation >> >> This document does not define, nor as far as I can tell, reference a >> concrete procedure for mapping an instant inbox (im: URL) to a SIP >> URL. If clients can enter in im: URLs, then the related protocols >> must specify a mechanism for securely performing this mapping. >> >> The protocol specifies how SDP is used to map SIP URLs to MSRP URLs. >> I do not have enough information about practical SIP deployments to >> know whether this mapping is secure in practice. IT seems possible >> to secure this mapping if the SDP information is encrypted. >> >> This document does not specify how to validate the certificates >> encrypted or signed messages. How do I know that a particular >> certificate corresponds to a particular principal? Should it include >> an im: URL, a sip: URL, an msrp: URL or some combination? Where >> should these addresses be placed? >> If the MSRP protocol is used to transport message/cpim content, the >> recipient needs to confirm that the sender address in the message/cpim >> corresponds to the expected sender. This is especially important in >> the case of signed messages. The protocol needs to specify a >> procedure for securely mapping an im: URL found in the message/cpim >> to the appropriate MSRP URL to validate the sender. >> >> The assumption that certificates used for TLS authentication for MSRP >> should belong to the host seems flawed. This might be a reasonable >> assumption for the relay mode, but seems incorrect for the >> peer-to-peer mode of the protocol. IN a peer-to-peer configuration, >> there may be multiple instances of MSRP on a given host in >> significantly different security domains. It seems necessary to >> authenticate MSRP, SIP ,r IM peers rather than to authenticate hosts. >> >> >> In practice, MSRP does not provide transport security in the >> peer-to-peer mode. The protocol allows for the use of TLS. However >> the spec points out that MSRP peers are not expected to have TLS >> certificates or stable hostnames for these certificates to be bound >> to. The lack of deployable transport security is a critical >> deficiency in the peer-to-peer mode of >> of MSRP. Transport security has proven an important part of securing >> XMPP. Most other message transport protocols in the IETF, including >> IMAP, SMTP, XMPP and APEX support transport security. >> The protocol provides support for S/MIME for end-to-end security. >> This is adequate to meet requirement 3 if the certificate naming >> issues are addressed. >> >> The protocol does not provide a mechanism to protect against passive >> attacks unless sufficient authentication infrastructure is available >> to use TLS. >> >> Recommendations >> >> 1) Decide on procedures for mapping im: URLs to sip: URLs. These >> procedures are not part of MSRP, but MSRP needs a normative >> reference to them. Note that RFC 3861 does not really answer this >> question. That specification tells you what machine to talk to in >> order to deliver an instant message. It does not tell you what >> sip: URL to present to that system. >> 2) Clearly state guidelines for dealing with the identities of message >> recipients and senders in S/MIME messages and message/cpim >> messages. Look at section 6 of draft-ietf-xmpp-e2e for examples of >> the types of things such guidelines need to say. >> >> 3) Re-examine the decision to use msrp: URLs. It is my understanding >> from the change history that previous versions of the draft simply >> used sip: URLs. That would be much easier to deal with from a >> security standpoint. If the working group does decide to use >> msrp: URLs, then the mapping needs to be carefully considered. >> >> 4) Reconsider the decision to split relay functionality into its own >> draft. I agree that for many configurations it is impossible to >> get good transport security without relay operation. Rather than >> relaxing the requirement for transport security, I believe that >> the working group should come to the conclusion that relay mode is >> an integral part of the protocol. Also, the current split does >> not work well because authentication to a relay is different than >> authentication to a peer. In authenticating to a relay, you are >> authenticating to a specific service running on a host. However >> when you authenticate to a peer, you are authenticating to a >> specific IM principal. The current draft does not properly handle >> this distinction and I don't think a split proposal can easily do >> so. Note that I have not evaluated the security of the relay >> proposal, but I have considered what security is possible to >> achieve given solutions to the relay problem. >> >> 5) Support SASL authentication and security layers for transport >> security in addition to TLS. This should be done for >> compatibility with the other IETF messaging protocols. In >> addition, some SASL modes such as digest-md5 or the user-to-user >> Kerberos mechanism could work well for peer-to-peer >> authentication. Providing implementers with this flexibility >> would be good. >> >> 6) Support TLS in an anonymous mode for protection against passive >> attacks. It's easy to do this given that you already support TLS >> and will provide useful benefits. >> >> 7) Consider handling of messages that appear to come from the same >> sender but are delivered over paths with different security >> properties. For example, Alice is in a conversation with >> im:bob@example.com over an MSRP session using both TLS and >> end-to-end S/MIME. How should Alice's client handle a message >> coming in over a different MSRP session using a different MSRP URL >> for the sender if that sender also maps back to im:bob@example.com? >> When is this acceptable from a security standpoint? >> >> >> Architectural Considerations >> >> While reviewing a document for security considerations, one often runs >> into issues unrelated to security. I discovered two such issues with >> this document: >> >> 1) No mechanism is provided for discovery of future extensions. >> However, section 12 anticipates that future IETF action may define >> such extensions. Significant experience has shown me that you >> want at least minimal discovery in your protocol. You want to be >> able to add a negotiation mechanism later and discover its >> presence. I recommend that MSRP clearly specify behavior if a >> client uses an undefined method. I recommend that this behavior >> be sufficient to discover whether the peer implements some method >> in the future. >> >> 2) Section 6 of RFC 3862 lists several application considerations that >> applications using RFC 3862 need to address. RFC 3860 does not >> address these considerations so MSRP must do so in order to >> completely specify the use of message/cpim. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 8 12:45:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26663; Wed, 8 Sep 2004 12:45:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C55cu-0004Pj-7R; Wed, 08 Sep 2004 12:49:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C55JD-0005CG-Fr; Wed, 08 Sep 2004 12:28:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C554C-0000nu-8T for simple@megatron.ietf.org; Wed, 08 Sep 2004 12:13:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24485 for ; Wed, 8 Sep 2004 12:13:01 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C557r-0003pd-3J for simple@ietf.org; Wed, 08 Sep 2004 12:16:52 -0400 Received: from [192.168.1.20] ([64.114.198.10]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i88GCxtm044171 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 8 Sep 2004 11:13:01 -0500 (CDT) (envelope-from RjS@xten.com) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: simple@ietf.org From: Robert Sparks Date: Wed, 8 Sep 2004 11:12:01 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Subject: [Simple] Proposed applicability statement for MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Folks - One of the things that Sam's review highlights is the need for a more explicit applicability statement in the MSRP specs. Here's a proposal for the text for such a statement. (We'll add references in the places that need them when we fold the result of this conversation into the spec). RjS --------------------------------------------------------- Applicability Statement: MSRP is not designed for use as a standalone protocol. MSRP MUST only be used in the context of a rendezvous mechanism meeting the following requirements: - The rendezvous mechanism MUST provide both MSRP URIs associated with an MSRP session to each of the participating endpoints. The rendezvous mechanism MUST implement mechanisms to provide these URIs securely - they MUST NOT be made available to an untrusted third party or be easily discoverable. - The rendezvous mechanism MUST provide mechanisms for the negotiation of any supported MSRP extensions that are not backwards compatible. - The rendezvous mechanism MUST be able to natively transport im: URIs or automatically translate im: URIs into the addressing identifiers of the rendezvous protocol. To use a rendezvous mechanism with MSRP, an RFC must be prepared describing how it exchanges MSRP URIs and meets these requirements listed here. This document provides such a description for the use of MSRP in the context of SIP/SDP. The Session Initiation Protocol (SIP) meets these requirements for a rendezvous mechanism. The MSRP URIs are exchanged using the Session Description Protocol (SDP) in an offer/answer exchange using SIP. The exchanged SDP can also be used to negotiate MSRP extensions. This SDP can be secured using any of the mechanisms available in SIP, including using sips to ensure transport security across intermediaries and S/MIME for end-to-end protection of the SDP entity. SIP can carry arbitrary URIs (including im: URIs) in the Request-URI, and procedures are available to map im: URIs to sip: or sips: URIs. It is expected that initial deployments of MSRP will use SIP as its rendezvous mechanism. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 8 13:22:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29004; Wed, 8 Sep 2004 13:22:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C56Cr-00057D-2c; Wed, 08 Sep 2004 13:26:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C563L-0008VS-U9; Wed, 08 Sep 2004 13:16:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C55u7-00065g-TR for simple@megatron.ietf.org; Wed, 08 Sep 2004 13:06:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28019 for ; Wed, 8 Sep 2004 13:06:40 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C55xn-0004ot-Ix for simple@ietf.org; Wed, 08 Sep 2004 13:10:32 -0400 Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i88H6Rpl002518; Wed, 8 Sep 2004 13:06:28 -0400 (EDT) Message-ID: <413F3BFC.3010109@dynamicsoft.com> Date: Wed, 08 Sep 2004 13:06:04 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Goeman Stefan Subject: Re: [Simple] Device priority References: <57FD2C3A246F76438CA6FDAD8FE9F195692173@hrtades7.atea.be> In-Reply-To: <57FD2C3A246F76438CA6FDAD8FE9F195692173@hrtades7.atea.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit inline. Goeman Stefan wrote: > Hello All, > > I have a small question. > Suppose I have two devices, a laptop and a mobile phone with the same > communication means ( they use same communication addresses). However, > if both devices are active (and registered), I would like to receive IM > on my laptop, and not on my phone. > > Is there a way to express to express the priority of the laptop over the > mobile phone for receiving IMs? I do not (immediately) find this in the > relevant RFC and IDs. From a SIP perspective, the devices would register with different capabilities. See RFC 3840, which includes parameters to describe exactly this kidn of thing (support for IM vs. not). A presence server could then use this registration information to generate a presence document. In this case, it can be modelled a few ways (see the presence data model document, http://www.ietf.org/internet-drafts/draft-rosenberg-simple-presence-data-model-00.txt. The most natural in this case is to model this as two sepearate services, each running on a separate device. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 8 15:03:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06306; Wed, 8 Sep 2004 15:03:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C57ms-000747-SH; Wed, 08 Sep 2004 15:07:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C57hP-0001LV-VV; Wed, 08 Sep 2004 15:01:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C57cv-0006HR-O2 for simple@megatron.ietf.org; Wed, 08 Sep 2004 14:57:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05853 for ; Wed, 8 Sep 2004 14:57:03 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C57gd-0006uN-CU for simple@ietf.org; Wed, 08 Sep 2004 15:00:55 -0400 Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i88Iuspl002598; Wed, 8 Sep 2004 14:56:54 -0400 (EDT) Message-ID: <413F55DE.4010702@dynamicsoft.com> Date: Wed, 08 Sep 2004 14:56:30 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Cridland Subject: Re: [Simple] XCAP as general configuration protocol. References: <20040812133605.10496.59603.polymer@peirce.gestalt.entity.net> <412F2D3B.5000609@dynamicsoft.com> <20040831164558.22087.7373.polymer@peirce.gestalt.entity.net> In-Reply-To: <20040831164558.22087.7373.polymer@peirce.gestalt.entity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Cc: SIP for Instant Messaging and Presence Leveraging Extensions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit Sorry again for the week long lag in my responses - finally found some time today to unbury myself from email backlog. Responses inline. Dave Cridland wrote: > On Fri Aug 27 13:46:51 2004, Jonathan Rosenberg wrote: > >> Dave Cridland wrote: >> >>> I'm a little confused by XCAP's purpose - is it aimed at providing a >>> configuration protocol specifically for the needs of SIMPLE's >>> protocol suite, or is it aimed at providing generalized configuration >>> access? > > > >>> 1) How do vendor-specific extensions work? (Say, if an addressbook or >>> bookmark collection were stored in XCAP, how would an application >>> add its own data to it?) Is this handled purely by namespaces, or >>> does that interfere with the Schemas defined? >> >> >> Each of the schemas in an application usage defines points where >> extensions can add additional information. That additional information >> would come from a different namespace. >> >> > Predefined points? How does the designer know where extension might be > required? Thats part of the task of designing the schema. There are many examples throughout XML document designs. >> >> The following spec defines a format for differences in documents: >> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-package-02.txt >> >> These documents would get delivered in notifications, using a SIP event >> package: >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-04.txt >> >> >> > Ah... So XCAP requires SIP to be of any real use? As Joel pointed out, this is a matter of perspective. There are many envisioned uses where the change notifications are not needed. >>> I'm thinking particularly of, for instance, storing bookmarks in >>> XCAP, which would require some method to track which bookmarks had >>> been visited recently - in other words, every bookmark usage would >>> then invalidate the entire document. That's truly terrifying. >> >> >> I don't follow what you intend to store in the server. The bookmark >> URL and some kind of indication of when it was last visited? > > > Yes, exactly that. (And more, of course.) > > It's a useful feature which allows the notion of bookmarks and history > to merge, somewhat. I think that is achievable with XCAP. > > > Having read through your comments a little more, I think I understand > where XCAP fits in a little better. > > As I understand things, a typical XCAP client would: > > 1) Bootstrap its initial configuration with a GET request for the area > that interested it from XCAP. (I'm unclear how it might find the XCAP > server, but finding your configuration server is always fun.) THis is described for SIP elements in the above-mentioned document. > 2) Possibly using this information, acquire SIP. I don't know what it means to "acquire SIP". The client may or may not support SIP depending on what it needs to do. > 3) Write any changes using XCAP PUT and DELETE. Since PUT invalidates > the cache, ignore any result other than success or failure for PUT. In your specific example, I would expect the PUT to be made against the specific bookmark whose status is being updated, each of which would be a different URI. SO, a simple-minded XML doc might look like this: http://www.yahoo.com Sep 8, 2004 http://www.ietf.org Sep 8, 2004 If I visit the ietf site, the browser would do something like this: PUT http://xcap.example.com/bookmarks/users/joe/index/~~/bookmarks/site[@name="ietf"]/last-visited Sep 9, 2004 > 4) Listen constantly for updates via SIP. Are you expecting multiple clients to be updating the same bookmark file? > 5) On reconnect, use acquire SIP using cached data, and then use SIP to > resynchronize. If you don't want SIP, the other chocie is that the client can cache the etag for the document, and on re-connect, use HEAD to check if it has changed. If not, do nothing. If so, pull the whole new bookmark file. > > Is it not possible to handle the writes via SIP, which appears to be > required anyway? And if so, couldn't nearly all the complexity of XCAP > be dropped out to provide a very simple configuration bootstrap protocol? SIP doesnt do anything near what XCAP does. As such, there would be no savings in complexity. Its also well outside of the scope of SIP. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 8 17:23:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22723; Wed, 8 Sep 2004 17:23:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C59y7-0003PT-8M; Wed, 08 Sep 2004 17:27:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C59Zm-0004Nw-Ii; Wed, 08 Sep 2004 17:01:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C58tr-0004Km-1h for simple@megatron.ietf.org; Wed, 08 Sep 2004 16:18:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14787 for ; Wed, 8 Sep 2004 16:18:36 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C58xU-0000uF-CJ for simple@ietf.org; Wed, 08 Sep 2004 16:22:29 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 08 Sep 2004 13:20:48 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i88KHxIV020255; Wed, 8 Sep 2004 13:18:00 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALK14533; Wed, 8 Sep 2004 15:55:45 -0400 (EDT) Message-ID: <413F63C0.9020204@cisco.com> Date: Wed, 08 Sep 2004 15:55:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Goeman Stefan Subject: Re: [Simple] Device priority References: <57FD2C3A246F76438CA6FDAD8FE9F195692173@hrtades7.atea.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Adding to what Jonathan said: Goeman Stefan wrote: > Hello All, > > I have a small question. > Suppose I have two devices, a laptop and a mobile phone with the same > communication means ( they use same communication addresses). However, > if both devices are active (and registered), I would like to receive IM > on my laptop, and not on my phone. You say they use the same communication address. Since they are separate devices, they must have separate contact addresses. So it must be the Address of Record that is the same, which presumably is also the presentity address. There is some other detail you didn't provide: - Is the laptop limited to IM, or does it also do voice? (I presume the mobile phone does both.) - Do they use the same contact address for IM and voice? (sip for both.) Or do they use separate addresses for voice and IM? (e.g. sip: for voice, im: for IM.) > Is there a way to express to express the priority of the laptop over the > mobile phone for receiving IMs? I do not (immediately) find this in the > relevant RFC and IDs. > > The way I understand the format of the presence document (RFC3863) is > that it groups a number of communication addresses (contact means + > contact address), and these communication addresses are decoupled from > the devices or user agents (which is not a bad idea I think). > > > Can someone enlighten my here? > Thanks in advance! If the the laptop only does IM, then its contact can be assigned a higher priority than that the mobile phone contact(s). As Jonathan mentioned, capabilities can be used to describe that this one does IM and not voice. If they both do IM & voice, and they each use a single sip contact it gets a bit more tricky. With just two tuples you can't describe that one is better for IM, but not better for voice. To achieve this effect, you would have to publish two tuples for the laptop - one with the contact at a high priority, with capabilities of IM and not voice. Another tuple, with the same contact address but a lower priority, could show capabilties for both IM and voice. The mobile phone could be described by either one or two tuples, with capabilties and priorities assigned to achieve the kind of prioritization you want. If IM and voice are handled using different contact addresses then you are forced to have separate tuples anyway, and to describe the capabilities separately. And of course you can set the priorities as you wish. In some cases a useful presence document can be derived from registration information (particularly if you use callee capabilties in the registration). But in registration you aren't permitted to have two entries with the same contact address. So you can't derive a presence document that has two tuples with the same contact from registration. Either you must separately publish the presence doc, or else you must hack the registration - using multiple addresses for the same device in order to register it twice. But this isn't a good idea because it can result in the same device getting tried twice for the same call. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 8 19:57:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03834; Wed, 8 Sep 2004 19:57:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5CNl-00068U-Qj; Wed, 08 Sep 2004 20:01:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5CHX-0006QD-Kc; Wed, 08 Sep 2004 19:55:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5CFQ-0005qx-5m for simple@megatron.ietf.org; Wed, 08 Sep 2004 19:53:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03602 for ; Wed, 8 Sep 2004 19:53:06 -0400 (EDT) Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5CJA-000634-6m for simple@ietf.org; Wed, 08 Sep 2004 19:57:00 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by willow.neustar.com (8.12.8/8.11.6) with ESMTP id i88NqVZB028946; Wed, 8 Sep 2004 23:52:31 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Sep 2004 19:52:31 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF4155@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Robert Sparks'" , simple@ietf.org Subject: RE: [Simple] Security Review of draft-ietf-simple-message-session s-07 Date: Wed, 8 Sep 2004 19:52:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505 Cc: Ted Hardie , hartmans@mit.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 919b3965bd46f7460d234f848680b238 Sam, Thanks first of all for the good review of the protocol - you make a lot of important points below, and I think we will definitely need to make some changes to the MSRP specification as a result of your suggestions. Here's some notes for starters. ;) The most important of change, I think, is the applicability statement that Robert sent out separately today. I think the root cause of a number of the deficiencies you note below is that the reliance of MSRP on a higher-layer rendezvous mechanism isn't as obvious as the authors hoped. The mapping of MSRP URLs to SIP URIs is perhaps the foremost of the related issues you raise (your recommendation #3). To really understand the reliance of MSRP on SIP, you have to look at the way SIP and RTP interact for establishing multimedia calls. In a VoIP scenario, for example, SDP contains the IP and port to which RTP will be sent - this identifies an RTP endpoint. An MSRP URL serves the same function as an RTP IP/port; it is not intended to be a user identity as such, user identities are exchanged and authorized and so on at the SIP layer. Talk of difficulties "mapping" SIP URIs to MSRP URLs, therefore, I think, mistakes the applicability of MSRP a bit, just as I'd say if someone suggested we needed a way to "map" RTP IP/ports to SIP URIs. The relationship of a SIP URI to an MSRP URL is totally transient and contingent, just as the relationship between a SIP URI and any given RTP endpoint IP/port is contingent (I may use this phone today, but some different phone tomorrow). What binds a SIP URI to an RTP IP/port, temporarily, is SIP itself - a SIP INVITE is sent containing SDP that advertises where to send RTP. That RTP endpoint is meaningful only for the duration of the session resulting from the SDP offer/answer. The resulting binding is just as secure as SIP is - if SIP is used with integrity protection and confidentiality over the SDP body, then the binding between the identity in SIP and the RTP endpoint is a secure binding. All of this applies as well to MSRP. Without some SIP-like means of securely exchanging endpoint identifiers, then yes, the relationship between an end user's identity and an MSRP URL would be very uncertain. With the applicability more firmly in mind, though, I don't think there is really any "mapping" problem here. Similarly, I think the rendezvous protocol can (and in the case of SIP, does) provide the sort of functionality that you'd get from something like SASL (your recommendation #5). Digest auth is built into SIP, there are ways of doing EAP (and all that EAP potentially brings with it) in SIP. More important, establishing the identity of the participants in a session is SIP's responsibility, not the responsibility of something at the RTP/MSRP layer, given the binding established by SIP described above. While there are many threats that motivate channel security at the RTP/MSRP layer, I think TLS and S/MIME, collectively, can address those threats for MSRP, and they are documented in the MSRP specification. SIP/SDP can serve as a vehicle to deliver keying information (even self-signed certificates) between endpoints, as it does in the sdescriptions method of exchanging keys for sRTP (which has your bearing on recommendation #6). The statement that SASL should be used for 'compatibility with the other IETF messaging protocols' strikes me as a little odd, given that CPIM MSGFMT was designed to provide precisely that, and was specified in the IMPP WG to allow compatibility between IETF instant messaging systems based on different technologies. It's also worth noting that interworking between various IETF messaging protocols will almost certainly entail the presence of gateways, which suggests that an end-to-end security solution like S/MIME MSGFMT would be more suitable than a transport security system. Does that make sense, and persuade? This isn't to say that I imagine everything above to be obvious from the text of the draft today; we may need to make further clarifications beyond the applicability statement to get this across. But does the underlying story work, in your opinion? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Robert Sparks [mailto:RjS@xten.com] > Sent: Wednesday, September 08, 2004 8:21 AM > To: simple@ietf.org > Cc: Ted Hardie; hartmans@mit.edu > Subject: [Simple] Security Review of > draft-ietf-simple-message-sessions-07 > > > Folks: > > At Ted's request, Sam Hartman performed a security review of the MSRP > base specification. > Sam's identified some things we need to do, and several > things we need > to talk about. > The chairs, our technical advisor, or the editors of these > drafts will > be sending messages to > the list responding to these points individually over the next few > days, either with proposed text > or starting a discussion on the topic. > > Please read this carefully and send your comments to the list. > > Thanks, > > RjS > > Begin forwarded message: > > >> This document reviews > draft-ietf-simple-message-sessions-07.txt. That > >> document specifies the MSRP protocol. > >> > >> Protocol Overview > >> > >> The MSRP protocol is a deceptively simple protocol for transporting > >> messages in an instant messaging session. It provides two > operations: > >> a send request and a report request. Each request can generate a > >> response. Each endpoint is defined by a MSRP URL. The > URL contains > >> the typical host and port, as well as a resource that > identifies the > >> specific destination of a message. For example if Alice > and Bob are > >> talking, they will both have MSRP URLs corresponding to their > >> identities. MSRP specifies the optional use of TLS for transport > >> level protection. > >> > >> However the security picture is actually a lot more complicated. > >> First, the knowledge of the MSRP URL serves as authentication and > >> authorization information. Since clients do not > typically have TLS > >> certificates, a server knows it is talking to the right > party based on > >> the URL that party sends to and possibly based on the response URL > >> listed in the message. The URLs are used for > authorization in that > >> layers above MSRP deal with preventing spam and so it is important > >> that only parties authorized to send messages have the > MSRP URL. So > >> MSRP URLs need to be chosen with a strong random component and if > >> message integrity is desired, they need to be > >> transported with confidentiality. > >> SIP, the layer above MSRP is responsible for mapping SIP > or CPIM URLs > >> into MSRP URLs to set up a message session. This mapping > is security > >> critical because users are probably going to add SIP or > CPIM URLs to > >> their contact lists. So, to securely establish a connection, the > >> combination of SIP and MSRP must securely map the > user-entered URL to > >> an MSRP URL. > >> > >> MSRP also involves S/MIME and CPIM identities. If S/MIME > is used to > >> get end-to-end encryption then the names of the chosen certificates > >> must be verified. If message/cpim entities are sent, then the from > >> and to fields in these messages must be matched. > Typically the cpim > >> identities will be instant inbox URLs although perhaps > they could also > >> be SIP URLs in some cases. > >> > >> One final identity is important for MSRP security. The MSRP > >> specification requires that if TLS is used, the server > certificate be > >> for the hostname in the destination MSRP URL. This requirement for > >> the TLS identity has important security implications. > >> > >> > >> Security Requirements > >> > >> The draft does not specify a set of security requirements. > IT seems > >> reasonable to refer back to RFC 2779 for security requirements for > >> this protocol. > >> > >> I explicitly choose to distinguish confidentiality > protection at the > >> transport layer from end-to-end confidentiality/integrity > protection. > >> RFC 2779 doesn't quite explicitly make this distinction, > but it does > >> require both integrity protection and support for digital > signatures. > >> This distinction seems reasonable for several reasons. > First, other > >> IM protocols including XMPP and APEX support both levels of > >> protection. We've found with email that end-to-end encryption and > >> transport level encryption are both useful; it seems likely that we > >> will see the same thing with IM. > >> > >> I also introduce the concept of parties sharing a deployed > >> authentication infrastructure. Ideally, we'd have some > authentication > >> infrastructure we could use to exchange key material with anyone on > >> the Internet. In practice, we do not yet have this level > of security > >> integration. However we should try to provide security in > >> environments where we can do so. Note that it is not acceptable to > >> force people to deploy a new authentication infrastructure for your > >> protocol if they already have an adequate infrastructure for some > >> other purpose. If you can work within that > infrastructure, then you > >> significantly decrease deployment costs of making your protocol > >> secure. > >> > >> 1) In order to provide integrity protection, the protocol must > >> describe how identifiers entered by the user are securely > mapped to > >> identifiers used in the protocol. The protocol must describe > >> necessary verifications of these mappings that recipients > of messages > >> need to perform in order to make sure they all refer to the same > >> principal. > >> > >> 2) When two parties share an appropriate authentication > >> infrastructure,then the protocol will provide a way for them to get > >> hop-by-hop confidentiality and integrity. > >> > >> 3) When two parties share an appropriate authentication > >> infrastructure, then the protocol will provide a mechanism for > >> end-to-end confidentiality and integrity. > >> > >> 4) Even when no authentication infrastructure is shared, > the protocol > >> will provide protection against passive attacks. > >> > >> Security Evaluation > >> > >> This document does not define, nor as far as I can tell, > reference a > >> concrete procedure for mapping an instant inbox (im: URL) to a SIP > >> URL. If clients can enter in im: URLs, then the related protocols > >> must specify a mechanism for securely performing this mapping. > >> > >> The protocol specifies how SDP is used to map SIP URLs to > MSRP URLs. > >> I do not have enough information about practical SIP deployments to > >> know whether this mapping is secure in practice. IT > seems possible > >> to secure this mapping if the SDP information is encrypted. > >> > >> This document does not specify how to validate the certificates > >> encrypted or signed messages. How do I know that a particular > >> certificate corresponds to a particular principal? Should > it include > >> an im: URL, a sip: URL, an msrp: URL or some combination? Where > >> should these addresses be placed? > >> If the MSRP protocol is used to transport message/cpim content, the > >> recipient needs to confirm that the sender address in the > message/cpim > >> corresponds to the expected sender. This is especially > important in > >> the case of signed messages. The protocol needs to specify a > >> procedure for securely mapping an im: URL found in the > message/cpim > >> to the appropriate MSRP URL to validate the sender. > >> > >> The assumption that certificates used for TLS > authentication for MSRP > >> should belong to the host seems flawed. This might be a reasonable > >> assumption for the relay mode, but seems incorrect for the > >> peer-to-peer mode of the protocol. IN a peer-to-peer > configuration, > >> there may be multiple instances of MSRP on a given host in > >> significantly different security domains. It seems necessary to > >> authenticate MSRP, SIP ,r IM peers rather than to > authenticate hosts. > >> > >> > >> In practice, MSRP does not provide transport security in the > >> peer-to-peer mode. The protocol allows for the use of > TLS. However > >> the spec points out that MSRP peers are not expected to have TLS > >> certificates or stable hostnames for these certificates to be bound > >> to. The lack of deployable transport security is a critical > >> deficiency in the peer-to-peer mode of > >> of MSRP. Transport security has proven an important part > of securing > >> XMPP. Most other message transport protocols in the > IETF, including > >> IMAP, SMTP, XMPP and APEX support transport security. > >> The protocol provides support for S/MIME for end-to-end security. > >> This is adequate to meet requirement 3 if the certificate naming > >> issues are addressed. > >> > >> The protocol does not provide a mechanism to protect > against passive > >> attacks unless sufficient authentication infrastructure is > available > >> to use TLS. > >> > >> Recommendations > >> > >> 1) Decide on procedures for mapping im: URLs to sip: URLs. These > >> procedures are not part of MSRP, but MSRP needs a normative > >> reference to them. Note that RFC 3861 does not really > answer this > >> question. That specification tells you what machine > to talk to in > >> order to deliver an instant message. It does not tell you what > >> sip: URL to present to that system. > >> 2) Clearly state guidelines for dealing with the > identities of message > >> recipients and senders in S/MIME messages and message/cpim > >> messages. Look at section 6 of draft-ietf-xmpp-e2e for > examples of > >> the types of things such guidelines need to say. > >> > >> 3) Re-examine the decision to use msrp: URLs. It is my > understanding > >> from the change history that previous versions of the > draft simply > >> used sip: URLs. That would be much easier to deal with from a > >> security standpoint. If the working group does decide to use > >> msrp: URLs, then the mapping needs to be carefully considered. > >> > >> 4) Reconsider the decision to split relay functionality > into its own > >> draft. I agree that for many configurations it is > impossible to > >> get good transport security without relay operation. > Rather than > >> relaxing the requirement for transport security, I believe that > >> the working group should come to the conclusion that > relay mode is > >> an integral part of the protocol. Also, the current > split does > >> not work well because authentication to a relay is > different than > >> authentication to a peer. In authenticating to a > relay, you are > >> authenticating to a specific service running on a > host. However > >> when you authenticate to a peer, you are authenticating to a > >> specific IM principal. The current draft does not > properly handle > >> this distinction and I don't think a split proposal > can easily do > >> so. Note that I have not evaluated the security of the relay > >> proposal, but I have considered what security is possible to > >> achieve given solutions to the relay problem. > >> > >> 5) Support SASL authentication and security layers for transport > >> security in addition to TLS. This should be done for > >> compatibility with the other IETF messaging protocols. In > >> addition, some SASL modes such as digest-md5 or the > user-to-user > >> Kerberos mechanism could work well for peer-to-peer > >> authentication. Providing implementers with this flexibility > >> would be good. > >> > >> 6) Support TLS in an anonymous mode for protection against passive > >> attacks. It's easy to do this given that you already > support TLS > >> and will provide useful benefits. > >> > >> 7) Consider handling of messages that appear to come from the same > >> sender but are delivered over paths with different security > >> properties. For example, Alice is in a conversation with > >> im:bob@example.com over an MSRP session using both TLS and > >> end-to-end S/MIME. How should Alice's client handle a message > >> coming in over a different MSRP session using a > different MSRP URL > >> for the sender if that sender also maps back to > im:bob@example.com? > >> When is this acceptable from a security standpoint? > >> > >> > >> Architectural Considerations > >> > >> While reviewing a document for security considerations, > one often runs > >> into issues unrelated to security. I discovered two such > issues with > >> this document: > >> > >> 1) No mechanism is provided for discovery of future extensions. > >> However, section 12 anticipates that future IETF > action may define > >> such extensions. Significant experience has shown me that you > >> want at least minimal discovery in your protocol. You > want to be > >> able to add a negotiation mechanism later and discover its > >> presence. I recommend that MSRP clearly specify behavior if a > >> client uses an undefined method. I recommend that > this behavior > >> be sufficient to discover whether the peer implements > some method > >> in the future. > >> > >> 2) Section 6 of RFC 3862 lists several application > considerations that > >> applications using RFC 3862 need to address. RFC 3860 does not > >> address these considerations so MSRP must do so in order to > >> completely specify the use of message/cpim. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 8 21:17:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09134; Wed, 8 Sep 2004 21:17:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5Dcn-0007PW-Qw; Wed, 08 Sep 2004 21:21:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5DUx-0006y6-VT; Wed, 08 Sep 2004 21:13:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5DQJ-0005vn-5s for simple@megatron.ietf.org; Wed, 08 Sep 2004 21:08:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08700 for ; Wed, 8 Sep 2004 21:08:25 -0400 (EDT) Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5DU4-0007HQ-4k for simple@ietf.org; Wed, 08 Sep 2004 21:12:20 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by willow.neustar.com (8.12.8/8.11.6) with ESMTP id i8917tZB030185; Thu, 9 Sep 2004 01:07:55 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Sep 2004 21:07:55 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF4156@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Robert Sparks'" , simple@ietf.org Subject: on relays (was RE: [Simple] Security Review of draft-ietf-simple- message-sessions-07) Date: Wed, 8 Sep 2004 21:07:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Ted Hardie , hartmans@mit.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Sam, Next topic. Relays (your recommendation #4). While I recognize that other messaging protocols developed here in the IETF have made relays an integral part of their operation, I'm very reluctant to make relays mandatory for MSRP, as compelling as the transport security argument may be. First of all, let me be clear that I'm talking about MSRP relays, not SIP-layer relays like SIP proxy servers. SIP proxies can and should play a number of important roles in allowing MSRP endpoints to discover one another, exchange SDP necessarily to the establishment of MSRP, provide security properties (like hop-by-hop TLS, as described in RFC3261 26.3.2.2), and implement various sorts of operator policies that are irrespective of the -contents- of the MSRP session. All of that stuff is very important, has to be provided by an intermediary, and is totally unrelated to whether or not MSRP relays even exist. The presence of relays in the operation of a protocol like RTP or MSRP is a cause of latency, additional single points of failure, additional state being kept in the network, and additional security concerns (because even relays could misbehave) - all of the general problems that arise when you don't follow the end-to-end model. In my view, the main reason why MSRP relays exist at all is NATs - they facilitate NAT traversal. There are also some other corner-cases, like IM logging in accordance with enterprise policies, aggregating transport-layer connections between service providers, and so on. But primarily, MSRP relays exist to compensate for a lack of network-layer connectivity/addressibility between MSRP endpoints. While it might seem attractive to say that MSRP endpoints could always use TLS to connect to a relay that they trust, the same way we do this in SIP, and thus guarantee that TLS can always be used for MSRP, there are many levels of trust: - You can trust a relay to forward your messages - You can trust a relay not to modify your messages - You can trust a relay not to read your messages Any relay that could pass the simplest empirical test has to forward your messages, at least. But if you're concerned about a relay modifying or reading your messages, you'll need to use something like S/MIME to prevent that. S/MIME credentials (even self-signed certs) could have been passed at the SIP/SDP layer during the establishment of the session in a secure manner that neither SIP relays nor MSRP relays would be able to thwart. [As an aside, of course, S/MIME can also provide the necessary end-to-end authentication through relays, to speak to your second point in recommendation #4 below.] But this shows the core issue I have with mandating relay use for its security properties. You've introduced another entity could be eavesdropping, and thus you have to use S/MIME to send messages through relays if you want real security. But if you use S/MIME, you already have the end-to-end security that you need - you can just use S/MIME between the endpoints without relays. So what is the security property we really gain from relays? These gradations of trust are much more important when considering MSRP relays than they are in considering SIP relays. You are only required to trust a SIP proxy server with one piece of salient information, really - that you want to have a session with a particular someone. You trust the SIP proxy with the identity of that particular someone because you have to - that SIP proxy is the only entity that knows how to reach that particular someone. Once the SIP proxy has connected you to that someone, its job is to get outta your way and let you chat. The only reason I need to trust an MSRP proxy is so that it can get me around a network-layer discontinuity (or to fulfill some operator policy corner-case). I don't want or need to trust it with the contents of my messages; it shouldn't need to have to inspect them to provide me network-layer connectivity with someone. If I don't need that NAT traversal job done, I don't want to run the risk or the cost (in latency or operational expense) of dealing with an MSRP relay at all. If the end-to-end model hasn't already been broken for some other reason (by a NAT, or something), I don't want to break it unnecessarily. I think the practice of using S/MIME in the absence of relays is described pretty well already in the fifth and sixth paragraphs of the Security Considerations of the MSRP spec. The threat model of relays is described in the MSRP relay draft, in Section 8.3. Does that seem reasonable? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Robert Sparks [mailto:RjS@xten.com] > Sent: Wednesday, September 08, 2004 8:21 AM > To: simple@ietf.org > Cc: Ted Hardie; hartmans@mit.edu > Subject: [Simple] Security Review of > draft-ietf-simple-message-sessions-07 > > [snip] > >> > >> 4) Reconsider the decision to split relay functionality > into its own > >> draft. I agree that for many configurations it is > impossible to > >> get good transport security without relay operation. > Rather than > >> relaxing the requirement for transport security, I believe that > >> the working group should come to the conclusion that > relay mode is > >> an integral part of the protocol. Also, the current > split does > >> not work well because authentication to a relay is > different than > >> authentication to a peer. In authenticating to a > relay, you are > >> authenticating to a specific service running on a > host. However > >> when you authenticate to a peer, you are authenticating to a > >> specific IM principal. The current draft does not > properly handle > >> this distinction and I don't think a split proposal > can easily do > >> so. Note that I have not evaluated the security of the relay > >> proposal, but I have considered what security is possible to > >> achieve given solutions to the relay problem. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 9 21:43:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25622; Thu, 9 Sep 2004 21:43:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5aW6-0002cI-P7; Thu, 09 Sep 2004 21:47:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5aPu-00062C-Bk; Thu, 09 Sep 2004 21:41:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5aNz-0005ag-Bd for simple@megatron.ietf.org; Thu, 09 Sep 2004 21:39:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25379 for ; Thu, 9 Sep 2004 21:39:33 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5aRw-0002X1-Cl for simple@ietf.org; Thu, 09 Sep 2004 21:43:41 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i8A1dPP6097231 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 9 Sep 2004 20:39:26 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <3E5B915F-02CA-11D9-A29E-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Simple WG From: Ben Campbell Date: Thu, 9 Sep 2004 20:39:23 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP Security Review Recommendation 7 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Hi, In Sam's security review (Thanks Sam!), his recommendation 7 was, and I paraphrase, that we should discuss what it means to have messages attributed to the same sender that arrive via different paths that may have different security properties. I interpret that to mean that the messages arrive on different MSRP sessions. So, here is some proposed text for discussion: ------------------------------------------------------------- It is possible that a recipient might receive messages that are attributed to the same sender via different MSRP sessions. For example, Alice might be in a conversation with Bob via an MSRP session over a TLS protected channel. Alice might then receive a different message from Bob over a different session, perhaps with a conference focus that asserts Bob's identity in a message/cpim envelope signed by the focus. MSRP does not in any way prohibit multiple simultaneous sessions between the same pair of identities. Nor does it prohibit an endpoint sending a message on behalf of another identity, such as may be the case for a conference focus. The recipient's endpoint should determine its level of trust of the authenticity of the sender independently for each session. The fact that an endpoint trusts the authenticity of the sender on any given session should not affect the level of trust it assigns for apparently the same sender on a different session. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 9 22:23:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27748; Thu, 9 Sep 2004 22:23:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5b8L-0003CX-FP; Thu, 09 Sep 2004 22:27:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5b3D-0004LE-F0; Thu, 09 Sep 2004 22:22:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5b2o-0004DS-TJ for simple@megatron.ietf.org; Thu, 09 Sep 2004 22:21:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27663 for ; Thu, 9 Sep 2004 22:21:44 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5b6m-0003As-C2 for simple@ietf.org; Thu, 09 Sep 2004 22:25:53 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i8A2LcF3000399 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 9 Sep 2004 21:21:39 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <23FE0A8C-02D0-11D9-A29E-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Simple WG From: Ben Campbell Date: Thu, 9 Sep 2004 21:21:36 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP Security Review: RFC3862 Application Considerations X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Hi, Sam's security review pointed out that we had not handled the application considerations required by RFC3862 on all applications using the message/cpim MIME type. Here is a first cut at those considerations for discussion (quoted text from RFC3862) > Applications using this specification must also specify: > > o all headers that must be recognized by implementations of the > application All MSRP endpoints MUST recognize the From, To, DateTime, and Require headers as defined in RFC3862. Such applications SHOULD recognize the CC header, and MAY recognize the Subject header. Any MSRP application that recognizes any message/cpim header MUST understand the NS (name space) header. > > o any headers that must be present in all messages created by that > application. All message/cpim body parts send by an MSRP endpoint MUST include the From and To headers. If the message/cpim body part is protected using S/MIME, then it SHOULD also include the DateTime header. > > o any headers that may appear more than once in a message, and how > they are to be interpreted (e.g., how to interpret multiple > 'Subject:' headers with different language parameter values). > Message/cpim headers defined in RFC 3862, with the exception of the NS header, MUST NOT occur more than once in a given message/cpim body part in an MSRP message. The Require header MAY include multiple values. The NS header MAY occur zero or more times, depending on how many name spaces are being referenced. Extension headers MAY occur more than once, depending on the definition of such headers. > o Security mechanisms and crytography schemes to be used with the > application, including any mandatory-to-implement security > provisions. [Ben: I _think_ we are covering this in general--do we need to explicitly relate such mechanisms to message/cpim?] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 10 04:01:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01767; Fri, 10 Sep 2004 04:01:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5gPP-0000JN-M4; Fri, 10 Sep 2004 04:05:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5gHe-0001HF-BN; Fri, 10 Sep 2004 03:57:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5gEt-0000ZH-RY for simple@megatron.ietf.org; Fri, 10 Sep 2004 03:54:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01391 for ; Fri, 10 Sep 2004 03:54:33 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5gIu-0008VQ-9q for simple@ietf.org; Fri, 10 Sep 2004 03:58:45 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8A7sIj08713; Fri, 10 Sep 2004 10:54:18 +0300 (EET DST) X-Scanned: Fri, 10 Sep 2004 10:54:12 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i8A7sCJp031669; Fri, 10 Sep 2004 10:54:12 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 000mpXuA; Fri, 10 Sep 2004 10:54:10 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8A7s9Y12619; Fri, 10 Sep 2004 10:54:09 +0300 (EET DST) Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Sep 2004 10:53:29 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Sep 2004 10:53:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP Security Review Recommendation 7 Date: Fri, 10 Sep 2004 10:53:28 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B5A0@esebe056.ntc.nokia.com> Thread-Topic: [Simple] MSRP Security Review Recommendation 7 Thread-Index: AcSW1+9dDyETLWx5RvSrEmEIQ3rtuQAMbCFw To: , X-OriginalArrivalTime: 10 Sep 2004 07:53:28.0558 (UTC) FILETIME=[4246B0E0:01C4970B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Sounds good, although I would not use the term "focus" (unless you want = to start referencing conferencing documents in sipping). Regards, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Ben Campbell > Sent: 10.September.2004 04:39 > To: Simple WG > Subject: [Simple] MSRP Security Review Recommendation 7 >=20 >=20 > Hi, >=20 > In Sam's security review (Thanks Sam!), his recommendation 7=20 > was, and I=20 > paraphrase, that we should discuss what it means to have messages=20 > attributed to the same sender that arrive via different paths=20 > that may=20 > have different security properties. I interpret that to mean that the=20 > messages arrive on different MSRP sessions. >=20 > So, here is some proposed text for discussion: >=20 > ------------------------------------------------------------- > It is possible that a recipient might receive messages that are=20 > attributed to the same sender via different MSRP sessions.=20 > For example,=20 > Alice might be in a conversation with Bob via an MSRP session over a =20 > TLS protected channel. Alice might then receive a different message=20 > from Bob over a different session, perhaps with a conference=20 > focus that=20 > asserts Bob's identity in a message/cpim envelope signed by the focus. >=20 > MSRP does not in any way prohibit multiple simultaneous sessions=20 > between the same pair of identities. Nor does it prohibit an endpoint=20 > sending a message on behalf of another identity, such as may be the=20 > case for a conference focus. The recipient's endpoint should=20 > determine=20 > its level of trust of the authenticity of the sender=20 > independently for=20 > each session. The fact that an endpoint trusts the=20 > authenticity of the=20 > sender on any given session should not affect the level of trust it=20 > assigns for apparently the same sender on a different session. >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 10 04:17:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02596; Fri, 10 Sep 2004 04:17:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5gfZ-0000Xc-5q; Fri, 10 Sep 2004 04:22:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5gaI-0004Fu-VZ; Fri, 10 Sep 2004 04:16:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5gWz-0003hR-OJ for simple@megatron.ietf.org; Fri, 10 Sep 2004 04:13:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02359 for ; Fri, 10 Sep 2004 04:13:07 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5gat-0000Tw-Q2 for simple@ietf.org; Fri, 10 Sep 2004 04:17:20 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8A8Cxj05261; Fri, 10 Sep 2004 11:12:59 +0300 (EET DST) X-Scanned: Fri, 10 Sep 2004 11:12:36 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i8A8Ca52015927; Fri, 10 Sep 2004 11:12:36 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00XxSznq; Fri, 10 Sep 2004 11:12:35 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8A8CZS00118; Fri, 10 Sep 2004 11:12:35 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Sep 2004 11:08:16 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Sep 2004 11:08:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP Security Review: RFC3862 Application Considerations Date: Fri, 10 Sep 2004 11:08:15 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B5A1@esebe056.ntc.nokia.com> Thread-Topic: [Simple] MSRP Security Review: RFC3862 Application Considerations Thread-Index: AcSW3WnYCHMz6Y4fRf67SFJfPlGgggAL3FCQ To: , X-OriginalArrivalTime: 10 Sep 2004 08:08:16.0708 (UTC) FILETIME=[53A7A040:01C4970D] X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Ben Campbell > Sent: 10.September.2004 05:22 > To: Simple WG > Subject: [Simple] MSRP Security Review: RFC3862 Application > Considerations >=20 >=20 > Hi, >=20 > Sam's security review pointed out that we had not handled the=20 > application considerations required by RFC3862 on all applications=20 > using the message/cpim MIME type. Here is a first cut at those=20 > considerations for discussion (quoted text from RFC3862) >=20 > > Applications using this specification must also specify: > > > > o all headers that must be recognized by implementations of the > > application >=20 > All MSRP endpoints MUST recognize the From, To, DateTime, and Require=20 > headers as defined in RFC3862. Such applications SHOULD recognize the=20 > CC header, and MAY recognize the Subject header. Any MSRP application=20 > that recognizes any message/cpim header MUST understand the NS (name=20 > space) header. >=20 > > > > o any headers that must be present in all messages=20 > created by that > > application. >=20 > All message/cpim body parts send by an MSRP endpoint MUST include the=20 > From and To headers. If the message/cpim body part is=20 > protected using=20 > S/MIME, then it SHOULD also include the DateTime header. >=20 > > > > o any headers that may appear more than once in a=20 > message, and how > > they are to be interpreted (e.g., how to interpret multiple > > 'Subject:' headers with different language parameter values). > > >=20 > Message/cpim headers defined in RFC 3862, with the exception=20 > of the NS=20 > header, MUST NOT occur more than once in a given message/cpim=20 > body part=20 > in an MSRP message. The Require header MAY include multiple=20 > values. The=20 > NS header MAY occur zero or more times, depending on how many name=20 > spaces are being referenced. >=20 > Extension headers MAY occur more than once, depending on the=20 > definition=20 > of such headers. The To-header field should not be limited to 1, nor should the CC field. = This could be used in the future for, what is commonly referred to as, = whispering or private messages within a conference. Also, the subject header might appear multiple times. I would say we = limit the from-header to one and no limit on the rest. Regards, Hisham >=20 > > o Security mechanisms and crytography schemes to be=20 > used with the > > application, including any mandatory-to-implement security > > provisions. >=20 > [Ben: I _think_ we are covering this in general--do we need to=20 > explicitly relate such mechanisms to message/cpim?] >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 10 09:24:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24299; Fri, 10 Sep 2004 09:24:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5lS3-0006Cb-FW; Fri, 10 Sep 2004 09:28:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5lKE-0002rX-5O; Fri, 10 Sep 2004 09:20:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5lIE-0002aA-Oj for simple@megatron.ietf.org; Fri, 10 Sep 2004 09:18:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23981 for ; Fri, 10 Sep 2004 09:18:20 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5lMI-00066E-6b for simple@ietf.org; Fri, 10 Sep 2004 09:22:35 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i8ADID68046057 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 10 Sep 2004 08:18:14 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <5816828233DEFA41807A6CFDFDF2343C08B5A1@esebe056.ntc.nokia.com> References: <5816828233DEFA41807A6CFDFDF2343C08B5A1@esebe056.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP Security Review: RFC3862 Application Considerations Date: Fri, 10 Sep 2004 08:18:11 -0500 To: X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit On Sep 10, 2004, at 3:08 AM, wrote: [...] >>> o any headers that may appear more than once in a >> message, and how >>> they are to be interpreted (e.g., how to interpret multiple >>> 'Subject:' headers with different language parameter values). >>> >> >> Message/cpim headers defined in RFC 3862, with the exception >> of the NS >> header, MUST NOT occur more than once in a given message/cpim >> body part >> in an MSRP message. The Require header MAY include multiple >> values. The >> NS header MAY occur zero or more times, depending on how many name >> spaces are being referenced. >> >> Extension headers MAY occur more than once, depending on the >> definition >> of such headers. > > The To-header field should not be limited to 1, nor should the CC > field. This could be used in the future for, what is commonly referred > to as, whispering or private messages within a conference. > > Also, the subject header might appear multiple times. I would say we > limit the from-header to one and no limit on the rest. > Good point on multiple To and CC values. I'm not sure how CC helps for whisper, I think you are looking for something like BCC, which is more of a function than a header. Nevertheless, I can see needing multiple CC values. > Regards, > Hisham > >> >>> o Security mechanisms and crytography schemes to be >> used with the >>> application, including any mandatory-to-implement security >>> provisions. >> >> [Ben: I _think_ we are covering this in general--do we need to >> explicitly relate such mechanisms to message/cpim?] >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 10 09:37:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25395; Fri, 10 Sep 2004 09:37:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5lfI-0006TD-Lm; Fri, 10 Sep 2004 09:42:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5lZ6-0006Do-To; Fri, 10 Sep 2004 09:35:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5lPn-0003qA-Uh for simple@megatron.ietf.org; Fri, 10 Sep 2004 09:26:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24451 for ; Fri, 10 Sep 2004 09:26:09 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5lTq-0006EG-OR for simple@ietf.org; Fri, 10 Sep 2004 09:30:24 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 10 Sep 2004 06:28:43 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8ADPT9N013494; Fri, 10 Sep 2004 06:25:30 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALL46191; Fri, 10 Sep 2004 09:25:35 -0400 (EDT) Message-ID: <4141AB4E.8060207@cisco.com> Date: Fri, 10 Sep 2004 09:25:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] MSRP Security Review: RFC3862 Application Considerations References: <5816828233DEFA41807A6CFDFDF2343C08B5A1@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Hisham, I agree with most of your comments, but I question the logic of multiple Subject headers. What does this mean? Is the actual subject the catenation of the contents of all the Subject headers? Should they have between then when displayed? Or are they to be treated as alternatives, such as the same subject represented in different languages? I believe 3261 only allows one Subject header. I don't know about email, but by common usage I don't think it would work well if there was more than one. Paul hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org]On Behalf >>Of ext Ben Campbell >>Sent: 10.September.2004 05:22 >>To: Simple WG >>Subject: [Simple] MSRP Security Review: RFC3862 Application >>Considerations >> >> >>Hi, >> >>Sam's security review pointed out that we had not handled the >>application considerations required by RFC3862 on all applications >>using the message/cpim MIME type. Here is a first cut at those >>considerations for discussion (quoted text from RFC3862) >> >> >>> Applications using this specification must also specify: >>> >>> o all headers that must be recognized by implementations of the >>> application >> >>All MSRP endpoints MUST recognize the From, To, DateTime, and Require >>headers as defined in RFC3862. Such applications SHOULD recognize the >>CC header, and MAY recognize the Subject header. Any MSRP application >>that recognizes any message/cpim header MUST understand the NS (name >>space) header. >> >> >>> o any headers that must be present in all messages >> >>created by that >> >>> application. >> >>All message/cpim body parts send by an MSRP endpoint MUST include the >> From and To headers. If the message/cpim body part is >>protected using >>S/MIME, then it SHOULD also include the DateTime header. >> >> >>> o any headers that may appear more than once in a >> >>message, and how >> >>> they are to be interpreted (e.g., how to interpret multiple >>> 'Subject:' headers with different language parameter values). >>> >> >>Message/cpim headers defined in RFC 3862, with the exception >>of the NS >>header, MUST NOT occur more than once in a given message/cpim >>body part >>in an MSRP message. The Require header MAY include multiple >>values. The >>NS header MAY occur zero or more times, depending on how many name >>spaces are being referenced. >> >>Extension headers MAY occur more than once, depending on the >>definition >>of such headers. > > > The To-header field should not be limited to 1, nor should the CC field. This could be used in the future for, what is commonly referred to as, whispering or private messages within a conference. > > Also, the subject header might appear multiple times. I would say we limit the from-header to one and no limit on the rest. > > Regards, > Hisham > > >>> o Security mechanisms and crytography schemes to be >> >>used with the >> >>> application, including any mandatory-to-implement security >>> provisions. >> >>[Ben: I _think_ we are covering this in general--do we need to >>explicitly relate such mechanisms to message/cpim?] >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 10 11:11:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04981; Fri, 10 Sep 2004 11:11:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5n7l-00009A-TR; Fri, 10 Sep 2004 11:15:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5n2N-0007Tm-Ne; Fri, 10 Sep 2004 11:10:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5mn3-0004DN-9h for simple@megatron.ietf.org; Fri, 10 Sep 2004 10:54:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03588 for ; Fri, 10 Sep 2004 10:54:14 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5mr7-00089p-F1 for simple@ietf.org; Fri, 10 Sep 2004 10:58:31 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i8AEr854053450 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 10 Sep 2004 09:53:09 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <4141AB4E.8060207@cisco.com> References: <5816828233DEFA41807A6CFDFDF2343C08B5A1@esebe056.ntc.nokia.com> <4141AB4E.8060207@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2049D4AF-0339-11D9-A29E-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP Security Review: RFC3862 Application Considerations Date: Fri, 10 Sep 2004 09:53:07 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Oops, in my hurry to reply about To and CC, I missed Subject. I also don't know what it means to have multiple subjects. The application considerations require us to document what it means to have more than one of any particular header that we allow multiples for. Hisham, did you have an application in mind? On Sep 10, 2004, at 8:25 AM, Paul Kyzivat wrote: > Hisham, > > I agree with most of your comments, but I question the logic of > multiple Subject headers. What does this mean? Is the actual subject > the catenation of the contents of all the Subject headers? Should they > have between then when displayed? Or are they to be treated > as alternatives, such as the same subject represented in different > languages? > > I believe 3261 only allows one Subject header. I don't know about > email, but by common usage I don't think it would work well if there > was more than one. > > Paul > > hisham.khartabil@nokia.com wrote: >>> -----Original Message----- >>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On >>> Behalf >>> Of ext Ben Campbell >>> Sent: 10.September.2004 05:22 >>> To: Simple WG >>> Subject: [Simple] MSRP Security Review: RFC3862 Application >>> Considerations >>> >>> >>> Hi, >>> >>> Sam's security review pointed out that we had not handled the >>> application considerations required by RFC3862 on all applications >>> using the message/cpim MIME type. Here is a first cut at those >>> considerations for discussion (quoted text from RFC3862) >>> >>> >>>> Applications using this specification must also specify: >>>> >>>> o all headers that must be recognized by implementations of the >>>> application >>> >>> All MSRP endpoints MUST recognize the From, To, DateTime, and >>> Require headers as defined in RFC3862. Such applications SHOULD >>> recognize the CC header, and MAY recognize the Subject header. Any >>> MSRP application that recognizes any message/cpim header MUST >>> understand the NS (name space) header. >>> >>> >>>> o any headers that must be present in all messages >>> >>> created by that >>> >>>> application. >>> >>> All message/cpim body parts send by an MSRP endpoint MUST include >>> the From and To headers. If the message/cpim body part is protected >>> using S/MIME, then it SHOULD also include the DateTime header. >>> >>> >>>> o any headers that may appear more than once in a >>> >>> message, and how >>> >>>> they are to be interpreted (e.g., how to interpret multiple >>>> 'Subject:' headers with different language parameter values). >>>> >>> >>> Message/cpim headers defined in RFC 3862, with the exception of the >>> NS header, MUST NOT occur more than once in a given message/cpim >>> body part in an MSRP message. The Require header MAY include >>> multiple values. The NS header MAY occur zero or more times, >>> depending on how many name spaces are being referenced. >>> >>> Extension headers MAY occur more than once, depending on the >>> definition of such headers. >> The To-header field should not be limited to 1, nor should the CC >> field. This could be used in the future for, what is commonly >> referred to as, whispering or private messages within a conference. >> Also, the subject header might appear multiple times. I would say we >> limit the from-header to one and no limit on the rest. >> Regards, >> Hisham >>>> o Security mechanisms and crytography schemes to be >>> >>> used with the >>> >>>> application, including any mandatory-to-implement security >>>> provisions. >>> >>> [Ben: I _think_ we are covering this in general--do we need to >>> explicitly relate such mechanisms to message/cpim?] >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 10 13:31:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15809; Fri, 10 Sep 2004 13:31:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5pJH-0003EX-Tf; Fri, 10 Sep 2004 13:35:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5p8v-0004JO-Oe; Fri, 10 Sep 2004 13:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5onJ-000859-V1 for simple@megatron.ietf.org; Fri, 10 Sep 2004 13:02:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13915 for ; Fri, 10 Sep 2004 13:02:38 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5orQ-0002fg-DJ for simple@ietf.org; Fri, 10 Sep 2004 13:06:56 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8AH0Hv06418; Fri, 10 Sep 2004 20:00:17 +0300 (EET DST) X-Scanned: Fri, 10 Sep 2004 20:00:07 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i8AH07Vg012590; Fri, 10 Sep 2004 20:00:07 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00a8uFQE; Fri, 10 Sep 2004 20:00:04 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8AGxhY25988; Fri, 10 Sep 2004 19:59:43 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Sep 2004 18:55:02 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Sep 2004 18:55:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP Security Review: RFC3862 Application Considerations Date: Fri, 10 Sep 2004 18:55:02 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B5AA@esebe056.ntc.nokia.com> Thread-Topic: [Simple] MSRP Security Review: RFC3862 Application Considerations Thread-Index: AcSXOhfxShP9yltaTzG6Jnps71FMHgAFGNDg To: X-OriginalArrivalTime: 10 Sep 2004 15:55:02.0823 (UTC) FILETIME=[8899A370:01C4974E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 10.September.2004 16:26 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: ben@nostrum.com; simple@ietf.org > Subject: Re: [Simple] MSRP Security Review: RFC3862 Application > Considerations >=20 >=20 > Hisham, >=20 > I agree with most of your comments, but I question the logic=20 > of multiple=20 > Subject headers. What does this mean? Is the actual subject the=20 > catenation of the contents of all the Subject headers? Should=20 > they have=20 > between then when displayed? Or are they to be treated as=20 > alternatives, such as the same subject represented in=20 > different languages? That's what I had in mind. /Hisham >=20 > I believe 3261 only allows one Subject header. I don't know=20 > about email,=20 > but by common usage I don't think it would work well if there=20 > was more=20 > than one. >=20 > Paul >=20 > hisham.khartabil@nokia.com wrote: > >=20 > >>-----Original Message----- > >>From: simple-bounces@ietf.org=20 > >>[mailto:simple-bounces@ietf.org]On Behalf > >>Of ext Ben Campbell > >>Sent: 10.September.2004 05:22 > >>To: Simple WG > >>Subject: [Simple] MSRP Security Review: RFC3862 Application > >>Considerations > >> > >> > >>Hi, > >> > >>Sam's security review pointed out that we had not handled the=20 > >>application considerations required by RFC3862 on all applications=20 > >>using the message/cpim MIME type. Here is a first cut at those=20 > >>considerations for discussion (quoted text from RFC3862) > >> > >> > >>> Applications using this specification must also specify: > >>> > >>> o all headers that must be recognized by implementations of the > >>> application > >> > >>All MSRP endpoints MUST recognize the From, To, DateTime,=20 > and Require=20 > >>headers as defined in RFC3862. Such applications SHOULD=20 > recognize the=20 > >>CC header, and MAY recognize the Subject header. Any MSRP=20 > application=20 > >>that recognizes any message/cpim header MUST understand the=20 > NS (name=20 > >>space) header. > >> > >> > >>> o any headers that must be present in all messages=20 > >> > >>created by that > >> > >>> application. > >> > >>All message/cpim body parts send by an MSRP endpoint MUST=20 > include the=20 > >> From and To headers. If the message/cpim body part is=20 > >>protected using=20 > >>S/MIME, then it SHOULD also include the DateTime header. > >> > >> > >>> o any headers that may appear more than once in a=20 > >> > >>message, and how > >> > >>> they are to be interpreted (e.g., how to interpret multiple > >>> 'Subject:' headers with different language parameter values). > >>> > >> > >>Message/cpim headers defined in RFC 3862, with the exception=20 > >>of the NS=20 > >>header, MUST NOT occur more than once in a given message/cpim=20 > >>body part=20 > >>in an MSRP message. The Require header MAY include multiple=20 > >>values. The=20 > >>NS header MAY occur zero or more times, depending on how many name=20 > >>spaces are being referenced. > >> > >>Extension headers MAY occur more than once, depending on the=20 > >>definition=20 > >>of such headers. > >=20 > >=20 > > The To-header field should not be limited to 1, nor should=20 > the CC field. This could be used in the future for, what is=20 > commonly referred to as, whispering or private messages=20 > within a conference. > >=20 > > Also, the subject header might appear multiple times. I=20 > would say we limit the from-header to one and no limit on the rest. > >=20 > > Regards, > > Hisham > >=20 > >=20 > >>> o Security mechanisms and crytography schemes to be=20 > >> > >>used with the > >> > >>> application, including any mandatory-to-implement security > >>> provisions. > >> > >>[Ben: I _think_ we are covering this in general--do we need to=20 > >>explicitly relate such mechanisms to message/cpim?] > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > >> > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 13 07:19:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16823; Mon, 13 Sep 2004 07:19:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6owa-0005J5-Tc; Mon, 13 Sep 2004 07:24:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6opf-0003el-Se; Mon, 13 Sep 2004 07:17:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6oos-0003Za-HL for simple@megatron.ietf.org; Mon, 13 Sep 2004 07:16:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16583 for ; Mon, 13 Sep 2004 07:16:25 -0400 (EDT) Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6otY-0005Fh-Sa for simple@ietf.org; Mon, 13 Sep 2004 07:21:17 -0400 Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for simple@ietf.org; Mon, 13 Sep 2004 13:15:54 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Sep 2004 13:15:53 +0200 Message-Id: <32BCBA960C20EB408F4BE7658522620D05B776C7@G9JJX.mgb01.telekom.de> From: "Alexeitsev, D" To: simple@ietf.org Date: Mon, 13 Sep 2004 13:15:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Simple] URI for Resource Lists X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Hi All, I would like to discuss the issue of resource lists URI starting with the introduction. Resource lists draft does not give much guidelines about the creation of URI for the resource lists. It is only says that it is a SIP URI and from the given examples one can assume that the URIs are taken from the same namespace as URIs for the "real" resources that actually provide presence information. I can see the idea behind looking at the resource lists from the namespace perspective just as at any other resource that one can subscribe to receive presence information. However such definition complicates the assignment of the URI to the "real" resources (subscribers) as one must check if the URI that subscriber has picked up (e.g. Web-Provisioning) is not only already taken by another subscriber, but also if it is not already somewhere taken for the resource list. Additionally there is no automatic provisioning at the UA, as subscribers will have to fill just another form to point to the resource list URI. A proposal would be to use something like user=resource-list URI parameter to separate this namespaces. Provisioning of the resource list URI in the UA could be done automatically by the UA, as it would be the same as the subscribers own URI with the the user=resource-list parameter. Surly extra resource lists URIs can be assign to the subscriber, but that would be a specific add-on for which subscribers will have to take the pain to manually provision them in to their UAs. Greetings, Denis Alexeitsev _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 13 08:56:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25113; Mon, 13 Sep 2004 08:56:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6qSA-0007Lf-Em; Mon, 13 Sep 2004 09:01:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6qGh-0006MO-2q; Mon, 13 Sep 2004 08:49:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6q8n-0005T1-6d for simple@megatron.ietf.org; Mon, 13 Sep 2004 08:41:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24088 for ; Mon, 13 Sep 2004 08:41:02 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6qDS-00071V-NG for simple@ietf.org; Mon, 13 Sep 2004 08:45:56 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 13 Sep 2004 05:49:18 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8DCeTsg001968; Mon, 13 Sep 2004 05:40:29 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALM48589; Mon, 13 Sep 2004 08:40:28 -0400 (EDT) Message-ID: <4145953B.8020400@cisco.com> Date: Mon, 13 Sep 2004 08:40:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexeitsev, D" Subject: Re: [Simple] URI for Resource Lists References: <32BCBA960C20EB408F4BE7658522620D05B776C7@G9JJX.mgb01.telekom.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Denis, I'm sure there are a multitude of ways to do this, and I'm not convinced it needs to be a matter for IETF standardization. Personally, I have been thinking that a resource list server would normally have a domain name distinct from that normally used for "user" AORs. For instance: - User AORs: sip:alice@acme.com - Resource list AORs: sip:alice-friends@lists.acme.com sip:retailers@lists.acme.com Paul Alexeitsev, D wrote: > Hi All, > > I would like to discuss the issue of resource lists URI starting with the introduction. > > Resource lists draft does not give much guidelines about the creation of URI for the resource lists. > > It is only says that it is a SIP URI and from the given examples one can assume that the URIs are taken from the same namespace as URIs for the "real" resources that actually provide presence information. > > I can see the idea behind looking at the resource lists from the namespace perspective just as at any other resource that one can subscribe to receive presence information. > > However such definition complicates the assignment of the URI to the "real" resources (subscribers) as one must check if the URI that subscriber has picked up (e.g. Web-Provisioning) is not only already taken by another subscriber, but also if it is not already somewhere taken for the resource list. > > Additionally there is no automatic provisioning at the UA, as subscribers will have to fill just another form to point to the resource list URI. > > A proposal would be to use something like user=resource-list URI parameter to separate this namespaces. Provisioning of the resource list URI in the UA could be done automatically by the UA, as it would be the same as the subscribers own URI with the the user=resource-list parameter. > > Surly extra resource lists URIs can be assign to the subscriber, but that would be a specific add-on for which subscribers will have to take the pain to manually provision them in to their UAs. > > Greetings, > Denis Alexeitsev > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 13 09:36:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29511; Mon, 13 Sep 2004 09:36:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6r5P-0008SM-Lu; Mon, 13 Sep 2004 09:41:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6quT-00057T-3r; Mon, 13 Sep 2004 09:30:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6qsS-0004mw-0K for simple@megatron.ietf.org; Mon, 13 Sep 2004 09:28:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28704 for ; Mon, 13 Sep 2004 09:28:14 -0400 (EDT) Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6qx8-0008Gp-ID for simple@ietf.org; Mon, 13 Sep 2004 09:33:08 -0400 Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 13 Sep 2004 15:27:42 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Sep 2004 15:27:42 +0200 Message-Id: <32BCBA960C20EB408F4BE7658522620D05B776CB@G9JJX.mgb01.telekom.de> From: "Alexeitsev, D" To: pkyzivat@cisco.com Subject: Re: [Simple] URI for Resource Lists Date: Mon, 13 Sep 2004 15:27:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hello Paul, Thanks for the reply. >I'm sure there are a multitude of ways to do this, and I'm not convinced >it needs to be a matter for IETF standardization. Well in my opinion if there are multitude of ways to do something, then it is definitely a topic for standardisation. In the case of resource lists I think even an information description of a common way for RLS naming would be helpful. Using a domain name differentiation is a nice one, are there any other views on the list? >Personally, I have been thinking that a resource list server would >normally have a domain name distinct from that normally used for "user" >AORs. >For instance: > >- User AORs: > sip:alice@acme.com > >- Resource list AORs: > sip:alice-friends@lists.acme.com > sip:retailers@lists.acme.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 13 10:05:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01630; Mon, 13 Sep 2004 10:05:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6rXN-0000ar-SB; Mon, 13 Sep 2004 10:10:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6rOR-0001eM-9V; Mon, 13 Sep 2004 10:01:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6rG1-0008Po-OJ for simple@megatron.ietf.org; Mon, 13 Sep 2004 09:52:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00558 for ; Mon, 13 Sep 2004 09:52:35 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6rKj-0000J3-5E for simple@ietf.org; Mon, 13 Sep 2004 09:57:29 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8DDqYv08365 for ; Mon, 13 Sep 2004 16:52:34 +0300 (EET DST) X-Scanned: Mon, 13 Sep 2004 16:52:04 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i8DDq4ds026481 for ; Mon, 13 Sep 2004 16:52:04 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 005ufwo5; Mon, 13 Sep 2004 16:52:03 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8DDpvS26333 for ; Mon, 13 Sep 2004 16:51:58 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 13 Sep 2004 16:51:56 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 13 Sep 2004 16:51:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Sep 2004 16:51:56 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B5C2@esebe056.ntc.nokia.com> Thread-Topic: CPCP Issue 37: Generic privileges solution Thread-Index: AcSZl/3YES5bsnqwSe+ryN/uBrPDqgAAL7cA To: X-OriginalArrivalTime: 13 Sep 2004 13:51:56.0747 (UTC) FILETIME=[D56521B0:01C49998] X-Spam-Score: 0.3 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Subject: [Simple] FW: CPCP Issue 37: Generic privileges solution X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable The draft can be found at: http://www.imsbook.com/hisham/draft-ietf-xcon-conference-policy-privilege= s-00.txt SIMPLE WG comments are being sorted on this issue presented below. Thanks, Hisham > -----Original Message----- > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > Sent: 13.September.2004 16:46 > To: 'xcon@ietf.org' > Subject: CPCP Issue 37: Generic privileges solution >=20 >=20 > This issue affects=20 > draft-ietf-xcon-conference-policy-privileges-00.txt. >=20 > The schema in this draft is generic and can be used for any=20 > XML document that carries user information and resides on a=20 > server. It is useful especially for XCAP. >=20 > I have been toying with the idea of extracting the schema=20 > into a separate draft and submitting that in SIMPLE. XCON can=20 > then use that draft and customise it for conferencing needs.=20 > By customising it, I mean defining the actions and=20 > transformations that grant the conferencing specific=20 > privileges to users. >=20 > This solution uses common policy as well where the conditions=20 > carry the document URI and the identity of users and the=20 > actions carry the privileges (read/modify certain parts of=20 > the conference policy). >=20 > BTW, the draft defines a sematic approach as agreed in San Diego. >=20 > So, what do people think of that? >=20 > I'll forward this email to SIMPLE for comments. >=20 > Regards, > Hisham >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 14 03:03:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09056; Tue, 14 Sep 2004 03:03:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C77Qd-0006xP-N1; Tue, 14 Sep 2004 03:08:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C77CN-0000dX-35; Tue, 14 Sep 2004 02:53:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C779d-0000Be-HG for simple@megatron.ietf.org; Tue, 14 Sep 2004 02:51:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08225 for ; Tue, 14 Sep 2004 02:51:02 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C77EO-0006jQ-D3 for simple@ietf.org; Tue, 14 Sep 2004 02:56:04 -0400 Received: from [192.168.1.117] ([64.114.198.10]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i8E6oNcm021444 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 14 Sep 2004 01:50:25 -0500 (CDT) (envelope-from RjS@xten.com) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <39AE3FC9-061A-11D9-A64D-000D93326732@xten.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: sip-implementors-request@cs.columbia.edu, simple@ietf.org From: Robert Sparks Date: Tue, 14 Sep 2004 01:49:29 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Simple] Registration for SIMPLEt 3 is open X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit SIMPLEt 3 will be held in Redmond, Washington November 1-3. This SIMPLEt is hosted by Microsoft, and there is no registration fee. All you need to attend is your own SIMPLE implementation to test. The event will be held in the Microsoft Platform Lab. See http://www.microsoftlab.net/ for information on how to get there and where to stay. If you're planning to attend, please register today by sending email to simplet3@microsoft.com. The registration deadline is October 25. You can find more information about the SIPITs and SIMPLEts at http://www.sipit.net/. See you in Redmond! RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 14 11:16:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17488; Tue, 14 Sep 2004 11:16:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7F7p-0008M6-Gj; Tue, 14 Sep 2004 11:21:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7Eq1-0003yP-BX; Tue, 14 Sep 2004 11:03:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7EiM-0002TR-Fh for simple@megatron.ietf.org; Tue, 14 Sep 2004 10:55:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15996 for ; Tue, 14 Sep 2004 10:55:20 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7En9-0007un-Rh for simple@ietf.org; Tue, 14 Sep 2004 11:00:28 -0400 Received: from [192.168.1.117] ([64.114.198.10]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i8EEt1ZK056372 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 14 Sep 2004 09:55:03 -0500 (CDT) (envelope-from RjS@xten.com) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: simple@ietf.org From: Robert Sparks Date: Tue, 14 Sep 2004 09:54:07 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Simple] Strength of XML validity requirements in SIMPLE documents X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Folks - We have several drafts that define XML documents. These drafts all say something along the lines of "The simple-filter is an XML document [8] that MUST be well-formed and SHOULD be valid." Why are we specifying SHOULD be valid instead of MUST? I'm asking this for both simple-filter and for the SIMPLE documents in general. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 14 14:30:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02407; Tue, 14 Sep 2004 14:30:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7I9k-0004A9-HB; Tue, 14 Sep 2004 14:35:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7HyS-0000ec-Tf; Tue, 14 Sep 2004 14:24:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7Huf-0008Jj-Ny for simple@megatron.ietf.org; Tue, 14 Sep 2004 14:20:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01742 for ; Tue, 14 Sep 2004 14:20:20 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7Hyk-0003xT-29 for simple@ietf.org; Tue, 14 Sep 2004 14:25:19 -0400 Received: from dynamicsoft.com ([63.113.46.152]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8EIInpl006024; Tue, 14 Sep 2004 14:18:52 -0400 (EDT) Message-ID: <414735F4.1070302@dynamicsoft.com> Date: Tue, 14 Sep 2004 14:18:28 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE documents References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Hmm, its a good question. I think that the vast majority of XML docs produced in the SIP/SIPPING/SIMPLE groups have the same words, and to be honest, I had not given a ton of thought to MUST vs. SHOULD for valid. I can't really think of a reason why it would ever be the right thing to produce a document that is not valid, particularly if the recipient does schema validation. Certainly I think the actual validation of documents should never be MUST, excepting rare cases like xcap when its a key part of the protocol. But, thats a different issue. -Jonathan R. Robert Sparks wrote: > Folks - > > We have several drafts that define XML documents. These drafts > all say something along the lines of > > "The simple-filter is an XML document [8] that MUST be well-formed and > SHOULD be valid." > > Why are we specifying SHOULD be valid instead of MUST? I'm asking > this for both simple-filter and for the SIMPLE documents in general. > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 15 12:37:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18201; Wed, 15 Sep 2004 12:37:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7cs4-0007Gx-HU; Wed, 15 Sep 2004 12:43:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7cHh-0006zB-5U; Wed, 15 Sep 2004 12:05:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7c6J-0003Xp-6h for simple@megatron.ietf.org; Wed, 15 Sep 2004 11:53:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14426 for ; Wed, 15 Sep 2004 11:53:40 -0400 (EDT) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7cBQ-0006Aa-Sj for simple@ietf.org; Wed, 15 Sep 2004 11:59:02 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8FFrdT13009 for ; Wed, 15 Sep 2004 18:53:39 +0300 (EET DST) X-Scanned: Wed, 15 Sep 2004 18:53:18 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i8FFrIfH024358 for ; Wed, 15 Sep 2004 18:53:18 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 004omCsQ; Wed, 15 Sep 2004 18:53:16 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8FFrGS05173 for ; Wed, 15 Sep 2004 18:53:16 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Sep 2004 18:53:05 +0300 Received: from agni.research.nokia.com (hed040-160.research.nokia.com [172.21.40.160]) by kusti.research.nokia.com (Postfix) with ESMTP id EC36F93B6A for ; Wed, 15 Sep 2004 18:53:04 +0300 (EEST) Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i8FFr4MM011903 for ; Wed, 15 Sep 2004 18:53:04 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i8FFr4aE011902; Wed, 15 Sep 2004 18:53:04 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: simple@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi Date: Wed, 15 Sep 2004 18:53:04 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 15 Sep 2004 15:53:05.0130 (UTC) FILETIME=[1683DCA0:01C49B3C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Simple] NOTIFY without message-body X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hello all SUBSCRIBE/NOTIFY lawyers, The RFC 3265 says that the NOTIFY sent in confirmation of a subscription MAY contain and empty or neutral body if the resource has no meaningful state. RFC 3856 (and partial-notify) also mention that a NOTIFY MAY be sent without a body. Now, what a subscriber does when he receives a NOTIFY with Content-Length: 0 in the middle of a subscription? Can he conclude that the event state is not meaningful anymore and ditch the state from previous NOTIFY? Or can he do that only if there is a Content-Type header in the NOTIFY? --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 15 13:18:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21494; Wed, 15 Sep 2004 13:18:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7dVg-0008EC-1V; Wed, 15 Sep 2004 13:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7dHh-0003Uy-7T; Wed, 15 Sep 2004 13:09:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7d9C-0001hg-Ld for simple@megatron.ietf.org; Wed, 15 Sep 2004 13:00:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20331 for ; Wed, 15 Sep 2004 13:00:43 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7dEK-0007t2-Mn for simple@ietf.org; Wed, 15 Sep 2004 13:06:06 -0400 Received: from dynamicsoft.com ([63.113.46.24]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8FH0Upl006695; Wed, 15 Sep 2004 13:00:31 -0400 (EDT) Message-ID: <41487517.9070308@dynamicsoft.com> Date: Wed, 15 Sep 2004 13:00:07 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Pessi Subject: Re: [Simple] NOTIFY without message-body References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit If the Content-TYpe is present, and the length is zero, it means that the body is of that type but has no information in it. I'll note that this is probably illegal, since a PIDF document is supposed to be valid/well-formed, and null content doesnt have that property. If the Content-Type is absent and the length is zero, it means that there is no body, and the state of the watched resource is unchanged. -Jonathan R. Pekka Pessi wrote: > Hello all SUBSCRIBE/NOTIFY lawyers, > > The RFC 3265 says that the NOTIFY sent in confirmation of a > subscription MAY contain and empty or neutral body if the resource > has no meaningful state. RFC 3856 (and partial-notify) also mention > that a NOTIFY MAY be sent without a body. > > Now, what a subscriber does when he receives a NOTIFY with > Content-Length: 0 in the middle of a subscription? Can he conclude > that the event state is not meaningful anymore and ditch the state > from previous NOTIFY? Or can he do that only if there is > a Content-Type header in the NOTIFY? > > --Pekka > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 15 13:27:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22033; Wed, 15 Sep 2004 13:27:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7deJ-0008Ma-NJ; Wed, 15 Sep 2004 13:32:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7dOm-0004QJ-1Q; Wed, 15 Sep 2004 13:16:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7dDO-0002eI-H2 for simple@megatron.ietf.org; Wed, 15 Sep 2004 13:05:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20566 for ; Wed, 15 Sep 2004 13:05:03 -0400 (EDT) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7dIW-0007y9-Sw for simple@ietf.org; Wed, 15 Sep 2004 13:10:26 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8FH4uj19379; Wed, 15 Sep 2004 20:04:56 +0300 (EET DST) X-Scanned: Wed, 15 Sep 2004 20:04:22 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i8FH4MFZ011738; Wed, 15 Sep 2004 20:04:22 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00l8pAyr; Wed, 15 Sep 2004 20:04:21 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8FH4KS08444; Wed, 15 Sep 2004 20:04:20 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Sep 2004 20:04:14 +0300 Received: from agni.research.nokia.com (hed040-160.research.nokia.com [172.21.40.160]) by kusti.research.nokia.com (Postfix) with ESMTP id 2A4D493B6A; Wed, 15 Sep 2004 20:04:14 +0300 (EEST) Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i8FH4EMM017067; Wed, 15 Sep 2004 20:04:14 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i8FH4BrY017066; Wed, 15 Sep 2004 20:04:11 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Jonathan Rosenberg Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE documents X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <414735F4.1070302@dynamicsoft.com> (Jonathan Rosenberg's message of "Tue, 14 Sep 2004 14:18:28 -0400") References: <414735F4.1070302@dynamicsoft.com> Date: Wed, 15 Sep 2004 20:04:11 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 15 Sep 2004 17:04:14.0718 (UTC) FILETIME=[076349E0:01C49B46] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Robert Sparks , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Jonathan Rosenberg writes: >Hmm, its a good question. I think that the vast majority of XML >docs produced in the SIP/SIPPING/SIMPLE groups have the same >words, and to be honest, I had not given a ton of thought to MUST >vs. SHOULD for valid. I can't really think of a reason why it >would ever be the right thing to produce a document that is not >valid, particularly if the recipient does schema validation. The presence documents may contain all kind of extensions, which may be only meaningful for a single application using the presence service. The presence servers or any intermediate nodes (not to speak about any innocent watcher) can't really know if the documents are valid unless they know the schema for all of those extensions. Like, if composer puts two tuples from two different sources to the combined document in the presence server. Both the extensions use ID attributes, but how could the composer know which attributes have xs:ID type? The following example may be valid, or then not, but who is to say without a schema? open --Pekka >Robert Sparks wrote: >> Folks - >> We have several drafts that define XML documents. These drafts >> all say something along the lines of >> "The simple-filter is an XML document [8] that MUST be well-formed and >> SHOULD be valid." >> Why are we specifying SHOULD be valid instead of MUST? I'm asking >> this for both simple-filter and for the SIMPLE documents in general. >> RjS >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 15 14:02:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24910; Wed, 15 Sep 2004 14:02:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7eBr-0000ma-Cj; Wed, 15 Sep 2004 14:07:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7e38-00056p-5N; Wed, 15 Sep 2004 13:58:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7dn7-0001mr-JS for simple@megatron.ietf.org; Wed, 15 Sep 2004 13:42:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23175 for ; Wed, 15 Sep 2004 13:41:59 -0400 (EDT) Received: from [64.69.76.4] (helo=dns1.xten.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7ds2-0000Di-0Y for simple@ietf.org; Wed, 15 Sep 2004 13:47:21 -0400 Received: from [24.84.40.103] by dns1.xten.net (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.5.3)); Wed, 15 Sep 2004 10:41:50 -0700 In-Reply-To: References: <414735F4.1070302@dynamicsoft.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3606370C-073E-11D9-886E-000D93326732@xten.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE documents Date: Wed, 15 Sep 2004 12:39:35 -0500 To: Pekka Pessi X-Mailer: Apple Mail (2.619) X-ArGoMail-Authenticated: robert@xten.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit This makes sense. For work going forward, we should have text in the document definition drafts that call out that this _kind_ of thing can happen. In the drafts that use the document, though, we might be able to be more strict. For instance, consider filter-format and filter-funct. Would it be helpful for filter format to say SHOULD be valid, but filter-funct say that a filter appearing in the body of a SUBSCRIBE MUST be valid? RjS On Sep 15, 2004, at 12:04 PM, Pekka Pessi wrote: > Jonathan Rosenberg writes: >> Hmm, its a good question. I think that the vast majority of XML >> docs produced in the SIP/SIPPING/SIMPLE groups have the same >> words, and to be honest, I had not given a ton of thought to MUST >> vs. SHOULD for valid. I can't really think of a reason why it >> would ever be the right thing to produce a document that is not >> valid, particularly if the recipient does schema validation. > > The presence documents may contain all kind of extensions, which > may be only meaningful for a single application using the presence > service. The presence servers or any intermediate nodes (not to > speak about any innocent watcher) can't really know if the > documents are valid unless they know the schema for all of > those extensions. > > Like, if composer puts two tuples from two different sources to > the combined document in the presence server. Both the extensions > use ID attributes, but how could the composer know which > attributes have xs:ID type? The following example may be valid, or > then not, but who is to say without a schema? > > > xmlns:x="http://example.com/ex/ten/sion" > entity="pres:john.doe@example.com"> > open > > > > --Pekka > >> Robert Sparks wrote: > >>> Folks - >>> We have several drafts that define XML documents. These drafts >>> all say something along the lines of >>> "The simple-filter is an XML document [8] that MUST be well-formed >>> and >>> SHOULD be valid." >>> Why are we specifying SHOULD be valid instead of MUST? I'm asking >>> this for both simple-filter and for the SIMPLE documents in general. >>> RjS >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 15 14:22:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26340; Wed, 15 Sep 2004 14:22:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7eVS-0001GJ-Sm; Wed, 15 Sep 2004 14:27:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7eFk-0007PZ-9S; Wed, 15 Sep 2004 14:11:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7e4g-0005RL-Ha for simple@megatron.ietf.org; Wed, 15 Sep 2004 14:00:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24778 for ; Wed, 15 Sep 2004 14:00:08 -0400 (EDT) Received: from web52808.mail.yahoo.com ([206.190.39.172]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C7e9p-0000hi-AW for simple@ietf.org; Wed, 15 Sep 2004 14:05:30 -0400 Message-ID: <20040915175938.86053.qmail@web52808.mail.yahoo.com> Received: from [195.155.247.46] by web52808.mail.yahoo.com via HTTP; Wed, 15 Sep 2004 10:59:38 PDT Date: Wed, 15 Sep 2004 10:59:38 -0700 (PDT) From: Fatih "Eyüp" NAR Subject: Re: [Simple] NOTIFY without message-body To: Jonathan Rosenberg , Pekka Pessi In-Reply-To: <41487517.9070308@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 does this comment only applicable to Notify or for all content embedded SIP-Requests? (ex:Register) ex:(as far as I saw/understood) if REGISTER with content/xml with content.length=0 is overriding the previously received/sent Register with content/xml with full body(i.e content.length>0) , which is legal . --- Jonathan Rosenberg wrote: > If the Content-TYpe is present, and the length is > zero, it means that > the body is of that type but has no information in > it. I'll note that > this is probably illegal, since a PIDF document is > supposed to be > valid/well-formed, and null content doesnt have that > property. > > If the Content-Type is absent and the length is > zero, it means that > there is no body, and the state of the watched > resource is unchanged. > > -Jonathan R. > > Pekka Pessi wrote: > > > Hello all SUBSCRIBE/NOTIFY lawyers, > > > > The RFC 3265 says that the NOTIFY sent in > confirmation of a > > subscription MAY contain and empty or neutral body > if the resource > > has no meaningful state. RFC 3856 (and > partial-notify) also mention > > that a NOTIFY MAY be sent without a body. > > > > Now, what a subscriber does when he receives a > NOTIFY with > > Content-Length: 0 in the middle of a subscription? > Can he conclude > > that the event state is not meaningful anymore and > ditch the state > > from previous NOTIFY? Or can he do that only if > there is > > a Content-Type header in the NOTIFY? > > > > --Pekka > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 > Lanidex Plaza > Chief Technology Officer > Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: > (973) 952-5050 > http://www.jdrosen.net PHONE: > (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 15 23:12:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19115; Wed, 15 Sep 2004 23:12:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7mmA-000404-6Q; Wed, 15 Sep 2004 23:17:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7mf2-0001UI-SG; Wed, 15 Sep 2004 23:10:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7mTi-000069-Jj for simple@megatron.ietf.org; Wed, 15 Sep 2004 22:58:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18118 for ; Wed, 15 Sep 2004 22:58:31 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7mYw-0003kd-EF for simple@ietf.org; Wed, 15 Sep 2004 23:03:59 -0400 Received: from dynamicsoft.com ([63.113.46.31]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8G2wFpl007038; Wed, 15 Sep 2004 22:58:16 -0400 (EDT) Message-ID: <41490131.8030207@dynamicsoft.com> Date: Wed, 15 Sep 2004 22:57:53 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Pessi Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE documents References: <414735F4.1070302@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Robert Sparks , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit inline. Pekka Pessi wrote: > Jonathan Rosenberg writes: > >>Hmm, its a good question. I think that the vast majority of XML >>docs produced in the SIP/SIPPING/SIMPLE groups have the same >>words, and to be honest, I had not given a ton of thought to MUST >>vs. SHOULD for valid. I can't really think of a reason why it >>would ever be the right thing to produce a document that is not >>valid, particularly if the recipient does schema validation. > > > The presence documents may contain all kind of extensions, which > may be only meaningful for a single application using the presence > service. The presence servers or any intermediate nodes (not to > speak about any innocent watcher) can't really know if the > documents are valid unless they know the schema for all of > those extensions. > > Like, if composer puts two tuples from two different sources to > the combined document in the presence server. Both the extensions > use ID attributes, but how could the composer know which > attributes have xs:ID type? The following example may be valid, or > then not, but who is to say without a schema? It depends on how you want to define "valid". If a document has some extensions (say, rpid ones), such a document is still valid according to just the pidf schema, since it contains well-formed elements from another namespace in a place allowed by the schema. So, when we say "SHOULD be valid", do we mean that all elements in the document should be valid according to their defined schemas, or just that the document is valid according to the pidf schema? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 16 00:02:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22248; Thu, 16 Sep 2004 00:02:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7nYX-0004zT-46; Thu, 16 Sep 2004 00:07:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7nMQ-0005Ip-Fw; Wed, 15 Sep 2004 23:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7nFs-0003RA-V0 for simple@megatron.ietf.org; Wed, 15 Sep 2004 23:48:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21608 for ; Wed, 15 Sep 2004 23:48:17 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7nL8-0004cU-8U for simple@ietf.org; Wed, 15 Sep 2004 23:53:46 -0400 Received: from dynamicsoft.com ([63.113.46.8]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8G3lGpl007093; Wed, 15 Sep 2004 23:48:10 -0400 (EDT) Message-ID: <41490CAE.70902@dynamicsoft.com> Date: Wed, 15 Sep 2004 23:46:54 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Fatih_=5C=22Ey=FCp=5C=22_NAR=22?= Subject: Re: [Simple] NOTIFY without message-body References: <20040915175938.86053.qmail@web52808.mail.yahoo.com> In-Reply-To: <20040915175938.86053.qmail@web52808.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id i8G3lGpl007093 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Cc: Pekka Pessi , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable It would be applicable to other requests where there is a=20 content/non-content choice that is meaningful. REGISTER is not a good=20 example since we don't actually define the meaning of content there.=20 UPDATE is a better example. It can have an SDP offer (CT:=20 application/sdp, CL: non-zero) or it can have none (no CT, CL: 0). There=20 also, a CT of application/sdp and a CL of zero is not valid, since a=20 null document would not be valid SDP. MESSAGE is another example. There, there can be a text message (CT:=20 text/plain, CL: non-zero), no content at all (no CT, CL: 0), or a=20 message with content that is "null" (CT: text/plain, CL: 0). -Jonathan R. Fatih Ey=FCp NAR wrote: > does this comment only applicable to Notify or for all > content embedded SIP-Requests? (ex:Register) >=20 > ex:(as far as I saw/understood) > if REGISTER with content/xml with content.length=3D0 is > overriding the previously received/sent Register with > content/xml with full body(i.e content.length>0) , > which is legal . >=20 > --- Jonathan Rosenberg > wrote: >=20 >=20 >>If the Content-TYpe is present, and the length is >>zero, it means that=20 >>the body is of that type but has no information in >>it. I'll note that=20 >>this is probably illegal, since a PIDF document is >>supposed to be=20 >>valid/well-formed, and null content doesnt have that >>property. >> >>If the Content-Type is absent and the length is >>zero, it means that=20 >>there is no body, and the state of the watched >>resource is unchanged. >> >>-Jonathan R. >> >>Pekka Pessi wrote: >> >> >>>Hello all SUBSCRIBE/NOTIFY lawyers, >>> >>>The RFC 3265 says that the NOTIFY sent in >> >>confirmation of a >> >>>subscription MAY contain and empty or neutral body >> >>if the resource >> >>>has no meaningful state. RFC 3856 (and >> >>partial-notify) also mention >> >>>that a NOTIFY MAY be sent without a body.=20 >>> >>>Now, what a subscriber does when he receives a >> >>NOTIFY with >> >>>Content-Length: 0 in the middle of a subscription? >> >>Can he conclude >> >>>that the event state is not meaningful anymore and >> >>ditch the state >> >>>from previous NOTIFY? Or can he do that only if >> >>there is >> >>>a Content-Type header in the NOTIFY? >>> >>>--Pekka >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> >>--=20 >>Jonathan D. Rosenberg, Ph.D. 600 >>Lanidex Plaza >>Chief Technology Officer =20 >>Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: =20 >>(973) 952-5050 >>http://www.jdrosen.net PHONE: >>(973) 952-5000 >>http://www.dynamicsoft.com >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> >=20 >=20 >=20 >=20 > =09 > =09 > __________________________________ > Do you Yahoo!? > New and Improved Yahoo! Mail - 100MB free storage! > http://promotions.yahoo.com/new_mail=20 >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 16 00:42:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24248; Thu, 16 Sep 2004 00:42:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7oBJ-0005ZB-Or; Thu, 16 Sep 2004 00:47:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7o2h-0005aA-1n; Thu, 16 Sep 2004 00:38:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7ntX-0004e4-Iu for simple@megatron.ietf.org; Thu, 16 Sep 2004 00:29:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23747 for ; Thu, 16 Sep 2004 00:29:16 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7nyn-0005ON-Cu for simple@ietf.org; Thu, 16 Sep 2004 00:34:45 -0400 Received: from dynamicsoft.com ([63.113.46.8]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8G4Scpl007138; Thu, 16 Sep 2004 00:28:38 -0400 (EDT) Message-ID: <41491660.1090203@dynamicsoft.com> Date: Thu, 16 Sep 2004 00:28:16 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexeitsev, D" Subject: Re: [Simple] URI for Resource Lists References: <32BCBA960C20EB408F4BE7658522620D05B776CB@G9JJX.mgb01.telekom.de> In-Reply-To: <32BCBA960C20EB408F4BE7658522620D05B776CB@G9JJX.mgb01.telekom.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: pkyzivat@cisco.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit A few comments here. Firstly, the XCAP resource list usage (http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-03.txt) provides a way for clients to request and/or create URIs for resource lists. This specification mandates that the server ensure that the URI provided for the resource list is unique within the domain. As you point out, this uniqueness requirement spans both other resource list URIs, and regular users in that domain. It would also include any other SIP resources - voicemail servers, applications, etc. I don't think we need to dictate how this gets done. I diagree that, just because there is variability, there needs to be standardization. Variability requires standardization only when, if one entity does something different than another, there are interop problems. I don't believe that is the case here. I believe this is squarely in the area of *policy*, and that is something we should stay far away from. Just like we don't dictate that your SIP URI has to be sip:.@your-domain.com, we should not dictate how resource list URIs look like. Thanks, Jonathan R. Alexeitsev, D wrote: > Hello Paul, > > Thanks for the reply. > > >> I'm sure there are a multitude of ways to do this, and I'm not >> convinced it needs to be a matter for IETF standardization. > > > Well in my opinion if there are multitude of ways to do something, > then it is definitely a topic for standardisation. In the case of > resource lists I think even an information description of a common > way for RLS naming would be helpful. > > Using a domain name differentiation is a nice one, are there any > other views on the list? > > > >> Personally, I have been thinking that a resource list server would >> normally have a domain name distinct from that normally used for >> "user" AORs. > > >> For instance: >> >> - User AORs: sip:alice@acme.com >> >> - Resource list AORs: sip:alice-friends@lists.acme.com >> sip:retailers@lists.acme.com > > > > _______________________________________________ Simple mailing list > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 16 03:42:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19296; Thu, 16 Sep 2004 03:42:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7r0B-0008U6-Qz; Thu, 16 Sep 2004 03:48:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7qp4-0004ed-EQ; Thu, 16 Sep 2004 03:36:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7qgx-0003pn-HM for simple@megatron.ietf.org; Thu, 16 Sep 2004 03:28:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18419 for ; Thu, 16 Sep 2004 03:28:29 -0400 (EDT) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7qmD-0008I5-Kr for simple@ietf.org; Thu, 16 Sep 2004 03:33:59 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8G7SKj24483; Thu, 16 Sep 2004 10:28:21 +0300 (EET DST) X-Scanned: Thu, 16 Sep 2004 10:27:15 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i8G7RFrn028245; Thu, 16 Sep 2004 10:27:15 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00fJeG83; Thu, 16 Sep 2004 10:27:14 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8G7R5Y11285; Thu, 16 Sep 2004 10:27:05 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 16 Sep 2004 10:26:50 +0300 Received: from nokia.com (xitami.research.nokia.com [172.21.40.110]) by kusti.research.nokia.com (Postfix) with ESMTP id 750E493B76; Thu, 16 Sep 2004 10:26:50 +0300 (EEST) Message-ID: <41493FDC.4000100@nokia.com> Date: Thu, 16 Sep 2004 10:25:16 +0300 From: Jari Urpalainen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE documents References: <414735F4.1070302@dynamicsoft.com> <41490131.8030207@dynamicsoft.com> In-Reply-To: <41490131.8030207@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Sep 2004 07:26:50.0726 (UTC) FILETIME=[885F6060:01C49BBE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: Pekka Pessi , Robert Sparks , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit ext Jonathan Rosenberg wrote: > inline. > > Pekka Pessi wrote: > >> Jonathan Rosenberg writes: >> >>> Hmm, its a good question. I think that the vast majority of XML >>> docs produced in the SIP/SIPPING/SIMPLE groups have the same >>> words, and to be honest, I had not given a ton of thought to MUST >>> vs. SHOULD for valid. I can't really think of a reason why it >>> would ever be the right thing to produce a document that is not >>> valid, particularly if the recipient does schema validation. >> >> >> >> The presence documents may contain all kind of extensions, which >> may be only meaningful for a single application using the presence >> service. The presence servers or any intermediate nodes (not to >> speak about any innocent watcher) can't really know if the >> documents are valid unless they know the schema for all of >> those extensions. >> >> Like, if composer puts two tuples from two different sources to >> the combined document in the presence server. Both the extensions >> use ID attributes, but how could the composer know which >> attributes have xs:ID type? The following example may be valid, or >> then not, but who is to say without a schema? > > > It depends on how you want to define "valid". If a document has some > extensions (say, rpid ones), such a document is still valid according > to just the pidf schema, since it contains well-formed elements from > another namespace in a place allowed by the schema. > > So, when we say "SHOULD be valid", do we mean that all elements in the > document should be valid according to their defined schemas, or just > that the document is valid according to the pidf schema? > > -Jonathan R. IMO pidf schema requirement is a "MUST" as content-type application/pidf+xml is defined by that schema. How could you use some instance document with that content-type if it is not valid ? For extensions, instance documents can use schemaLocation attribute, but it is only a hint to the validator. --Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 16 06:59:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00509; Thu, 16 Sep 2004 06:59:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7u4t-0004r0-Oy; Thu, 16 Sep 2004 07:05:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7tv3-0008Np-7X; Thu, 16 Sep 2004 06:55:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7tup-0008DN-9Q for simple@megatron.ietf.org; Thu, 16 Sep 2004 06:55:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29703 for ; Thu, 16 Sep 2004 06:55:00 -0400 (EDT) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7trx-0003vF-EO for simple@ietf.org; Thu, 16 Sep 2004 06:52:08 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8GAkUL27223; Thu, 16 Sep 2004 13:46:30 +0300 (EET DST) X-Scanned: Thu, 16 Sep 2004 13:46:15 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i8GAkFoc007939; Thu, 16 Sep 2004 13:46:15 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00GsjL0U; Thu, 16 Sep 2004 13:46:12 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8GAkCS12111; Thu, 16 Sep 2004 13:46:12 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 16 Sep 2004 13:45:59 +0300 Received: from agni.research.nokia.com (hed041-183.research.nokia.com [172.21.41.183]) by kusti.research.nokia.com (Postfix) with ESMTP id C9A9D93B75; Thu, 16 Sep 2004 13:45:58 +0300 (EEST) Received: from agni.research.nokia.com (news.netsonic.fi [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i8GAjwZK006076; Thu, 16 Sep 2004 13:45:58 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i8GAjw12006075; Thu, 16 Sep 2004 13:45:58 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Jonathan Rosenberg Subject: Re: [Simple] NOTIFY without message-body X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <41487517.9070308@dynamicsoft.com> (Jonathan Rosenberg's message of "Wed, 15 Sep 2004 13:00:07 -0400") References: <41487517.9070308@dynamicsoft.com> Date: Thu, 16 Sep 2004 13:45:58 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 16 Sep 2004 10:45:59.0742 (UTC) FILETIME=[5A8A85E0:01C49BDA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Pekka Pessi , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Hi Jonathan, >If the Content-TYpe is present, and the length is zero, it means that the >body is of that type but has no information in it. I'll note that this is >probably illegal, since a PIDF document is supposed to be valid/well-formed, >and null content doesnt have that property. >If the Content-Type is absent and the length is zero, it means that there is >no body, and the state of the watched resource is unchanged. OK. So, if I understood the specs correctly, the notifier can send a NOTIFY without body at any time. Now, let's assume that the subscriber is out of sync with, for instance, partial presence notifications. How it can ask the server to send a NOTIFY with full state? It could terminate and recreate the subscription, but that potentially involve a large number of message. --Pekka >Pekka Pessi wrote: >> Hello all SUBSCRIBE/NOTIFY lawyers, >> The RFC 3265 says that the NOTIFY sent in confirmation of a >> subscription MAY contain and empty or neutral body if the resource >> has no meaningful state. RFC 3856 (and partial-notify) also mention >> that a NOTIFY MAY be sent without a body. Now, what a subscriber does when >> he receives a NOTIFY with >> Content-Length: 0 in the middle of a subscription? Can he conclude >> that the event state is not meaningful anymore and ditch the state >> from previous NOTIFY? Or can he do that only if there is >> a Content-Type header in the NOTIFY? >> --Pekka >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 16 08:18:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06722; Thu, 16 Sep 2004 08:18:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7vIj-00074R-1w; Thu, 16 Sep 2004 08:23:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7vBP-0000Vc-L5; Thu, 16 Sep 2004 08:16:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7v3Y-0007Q6-JB for simple@megatron.ietf.org; Thu, 16 Sep 2004 08:08:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05901 for ; Thu, 16 Sep 2004 08:08:07 -0400 (EDT) Received: from cmailg3.svr.pol.co.uk ([195.92.195.173]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7v8r-0006nn-Ci for simple@ietf.org; Thu, 16 Sep 2004 08:13:38 -0400 Received: from user-1106.l4.c4.dsl.pol.co.uk ([81.79.228.82] helo=RW) by cmailg3.svr.pol.co.uk with smtp (Exim 4.14) id 1C7v3H-0005o3-9D; Thu, 16 Sep 2004 13:07:51 +0100 Message-ID: <001701c49be5$c9ce67e0$c700a8c0@RW> From: "Pete Cordell" To: "Jonathan Rosenberg" , "Pekka Pessi" References: <414735F4.1070302@dynamicsoft.com> Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE documents Date: Thu, 16 Sep 2004 13:07:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: Robert Sparks , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Please see below... ----- Original Message ----- From: "Pekka Pessi" > Jonathan Rosenberg writes: > >Hmm, its a good question. I think that the vast majority of XML > >docs produced in the SIP/SIPPING/SIMPLE groups have the same > >words, and to be honest, I had not given a ton of thought to MUST > >vs. SHOULD for valid. I can't really think of a reason why it > >would ever be the right thing to produce a document that is not > >valid, particularly if the recipient does schema validation. > > The presence documents may contain all kind of extensions, which > may be only meaningful for a single application using the presence > service. The presence servers or any intermediate nodes (not to > speak about any innocent watcher) can't really know if the > documents are valid unless they know the schema for all of > those extensions. > > Like, if composer puts two tuples from two different sources to > the combined document in the presence server. Both the extensions > use ID attributes, but how could the composer know which > attributes have xs:ID type? The following example may be valid, or > then not, but who is to say without a schema? > > > xmlns:x="http://example.com/ex/ten/sion" > entity="pres:john.doe@example.com"> > open > > > I don't know about the specifics of the presence schema, but presumably the original presence schema specifies at some key points. Hence the document is valid against the original schema. (Mumbo-jumbo is valid in the schema sense as long as it is from another namespace.) Put another way, a document can be valid in the schema sense, but still not be semantically correct. How validity is established for the extensions is another issue. This comes down to versioning. I think this is an area where the group(s) needs to get a common understanding on how things should be done. (Schema is actually weak in this area! There are ways, but they don't come for free and they certainly don't happen by accident!) Pete. -- ============================================= Pete Cordell Tech-Know-Ware pete(at)tech-know-ware.com http://www.tech-know-ware.com http://www.xml2cpp.com - Now Available +44 1473 635863 ============================================= > --Pekka > > >Robert Sparks wrote: ... cut ... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 16 12:30:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23822; Thu, 16 Sep 2004 12:30:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7zEm-0004YO-8g; Thu, 16 Sep 2004 12:36:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7z42-0001Ux-9Z; Thu, 16 Sep 2004 12:24:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7yq4-0005wV-4P for simple@megatron.ietf.org; Thu, 16 Sep 2004 12:10:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22359 for ; Thu, 16 Sep 2004 12:10:24 -0400 (EDT) Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7yvO-00040m-Dq for simple@ietf.org; Thu, 16 Sep 2004 12:15:59 -0400 Received: from g9jbq.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 16 Sep 2004 18:09:54 +0200 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Sep 2004 18:09:53 +0200 Message-Id: <32BCBA960C20EB408F4BE7658522620D05B776F4@G9JJX.mgb01.telekom.de> From: "Alexeitsev, D" To: jdrosen@dynamicsoft.com Subject: AW: [Simple] URI for Resource Lists Date: Thu, 16 Sep 2004 18:09:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: pkyzivat@cisco.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hello Jonathan Would then the sip:alice@example.com;user=lists meet the uniqueness requirement if there is already a resource named sip:alice@example.com? I assume that the example sip:alice@lists.example.com would meet this requirement as it is in the different domain as sip:alice@example.com >Firstly, the XCAP resource list usage >(http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-03.txt) >provides a way for clients to request and/or create URIs for resource >lists. This specification mandates that the server ensure that the URI >provided for the resource list is unique within the domain. As you point >out, this uniqueness requirement spans both other resource list URIs, >and regular users in that domain. It would also include any other SIP >resources - voicemail servers, applications, etc. Greetings, Denis Alexeitsev _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 16 20:00:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01002; Thu, 16 Sep 2004 20:00:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C86GW-0000GP-BO; Thu, 16 Sep 2004 20:06:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C869x-0007b2-SE; Thu, 16 Sep 2004 19:59:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8675-0006un-FA for simple@megatron.ietf.org; Thu, 16 Sep 2004 19:56:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00777 for ; Thu, 16 Sep 2004 19:56:27 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C86CV-0000A1-Hv for simple@ietf.org; Thu, 16 Sep 2004 20:02:07 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 16 Sep 2004 17:00:12 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8GNtq7Y006094; Thu, 16 Sep 2004 16:55:57 -0700 (PDT) Received: from cisco.com ([128.107.171.114]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALP63257; Thu, 16 Sep 2004 19:55:50 -0400 (EDT) Message-ID: <414A2806.2040009@cisco.com> Date: Thu, 16 Sep 2004 19:55:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] NOTIFY without message-body References: <20040915175938.86053.qmail@web52808.mail.yahoo.com> <41490CAE.70902@dynamicsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA00777 Cc: Pekka Pessi , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Jonathan, What you suggest is plausible, but I don't recall ever seeing anything=20 written that discusses the meaning of a Content-Type with an empty body. That logic would imply that there is (conceptually) a special content=20 type for which an empty body is valid and a non-empty body is not, and=20 that this is a default content-type when the body is empty. I believe I have seen stacks that considered the presence of a content=20 type header invalid if there is no body. At the least there ought to be=20 something that says this is valid usage. Paul Jonathan Rosenberg wrote: > It would be applicable to other requests where there is a=20 > content/non-content choice that is meaningful. REGISTER is not a good=20 > example since we don't actually define the meaning of content there.=20 > UPDATE is a better example. It can have an SDP offer (CT:=20 > application/sdp, CL: non-zero) or it can have none (no CT, CL: 0). Ther= e=20 > also, a CT of application/sdp and a CL of zero is not valid, since a=20 > null document would not be valid SDP. >=20 > MESSAGE is another example. There, there can be a text message (CT:=20 > text/plain, CL: non-zero), no content at all (no CT, CL: 0), or a=20 > message with content that is "null" (CT: text/plain, CL: 0). >=20 > -Jonathan R. >=20 > Fatih Ey=FCp NAR wrote: >=20 >> does this comment only applicable to Notify or for all >> content embedded SIP-Requests? (ex:Register) >> >> ex:(as far as I saw/understood) >> if REGISTER with content/xml with content.length=3D0 is >> overriding the previously received/sent Register with >> content/xml with full body(i.e content.length>0) , >> which is legal . >> >> --- Jonathan Rosenberg >> wrote: >> >> >>> If the Content-TYpe is present, and the length is >>> zero, it means that the body is of that type but has no information i= n >>> it. I'll note that this is probably illegal, since a PIDF document is >>> supposed to be valid/well-formed, and null content doesnt have that >>> property. >>> >>> If the Content-Type is absent and the length is >>> zero, it means that there is no body, and the state of the watched >>> resource is unchanged. >>> >>> -Jonathan R. >>> >>> Pekka Pessi wrote: >>> >>> >>>> Hello all SUBSCRIBE/NOTIFY lawyers, >>>> >>>> The RFC 3265 says that the NOTIFY sent in >>> >>> >>> confirmation of a >>> >>>> subscription MAY contain and empty or neutral body >>> >>> >>> if the resource >>> >>>> has no meaningful state. RFC 3856 (and >>> >>> >>> partial-notify) also mention >>> >>>> that a NOTIFY MAY be sent without a body. >>>> Now, what a subscriber does when he receives a >>> >>> >>> NOTIFY with >>> >>>> Content-Length: 0 in the middle of a subscription? >>> >>> >>> Can he conclude >>> >>>> that the event state is not meaningful anymore and >>> >>> >>> ditch the state >>> >>>> from previous NOTIFY? Or can he do that only if >>> >>> >>> there is >>> >>>> a Content-Type header in the NOTIFY? >>>> >>>> --Pekka >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >>> --=20 >>> Jonathan D. Rosenberg, Ph.D. 600 >>> Lanidex Plaza >>> Chief Technology Officer Parsippany, NJ 07054-2711 >>> dynamicsoft >>> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>> http://www.jdrosen.net PHONE: >>> (973) 952-5000 >>> http://www.dynamicsoft.com >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> >> >> >> =20 >> =20 >> __________________________________ >> Do you Yahoo!? >> New and Improved Yahoo! Mail - 100MB free storage! >> http://promotions.yahoo.com/new_mail >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 17 10:20:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08507; Fri, 17 Sep 2004 10:20:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8Jh6-0002nA-6E; Fri, 17 Sep 2004 10:26:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8JZ4-0003mF-W3; Fri, 17 Sep 2004 10:18:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8JY4-0003Ak-24 for simple@megatron.ietf.org; Fri, 17 Sep 2004 10:17:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08027 for ; Fri, 17 Sep 2004 10:17:13 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8Jda-0002hm-Hc for simple@ietf.org; Fri, 17 Sep 2004 10:22:59 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8HEHB100863 for ; Fri, 17 Sep 2004 17:17:12 +0300 (EET DST) X-Scanned: Fri, 17 Sep 2004 17:17:00 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i8HEH00f002643 for ; Fri, 17 Sep 2004 17:17:00 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00hVIPwO; Fri, 17 Sep 2004 17:16:57 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8HEGuY05986 for ; Fri, 17 Sep 2004 17:16:56 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 17 Sep 2004 17:16:55 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 17 Sep 2004 17:16:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Sep 2004 17:16:55 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B610@esebe056.ntc.nokia.com> Thread-Topic: Early review of MSRP Thread-Index: AcScwPxVmbLfpbW0SDOfViZ1AFs7EQ== To: X-OriginalArrivalTime: 17 Sep 2004 14:16:56.0266 (UTC) FILETIME=[FCD492A0:01C49CC0] X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Subject: [Simple] Early review of MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Whilst the design team is working on the security issues that were = recently brought up on the list, we are asking the community to review = the latest MSRP ID and send comments. The WGLC for MSRP will be issued = as soon as the security concerns have been tackled and an new ID has = been issued containing any modifications that may be required. Bringing up any issues now will allow us to close as many open issues as = soon as possible in parallel to solving the security ones. This will = reduce the number of issues that will be brought up during the MSRP WGLC = and will speed up the process of sending the draft to IESG (and = hopefully keep the MSRP design team sane :) The latest draft can be found at = http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-08= .txt Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 17 14:48:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27129; Fri, 17 Sep 2004 14:48:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8NsY-0000zZ-VD; Fri, 17 Sep 2004 14:54:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8Ngh-0007aB-72; Fri, 17 Sep 2004 14:42:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8NZe-0006IQ-AC for simple@megatron.ietf.org; Fri, 17 Sep 2004 14:35:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26369 for ; Fri, 17 Sep 2004 14:35:08 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8NfE-0000gg-Fv for simple@ietf.org; Fri, 17 Sep 2004 14:40:56 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i8HIYHak001816 for ; Fri, 17 Sep 2004 14:34:22 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Sep 2004 14:31:52 -0400 Message-ID: From: Eric Burger To: simple@ietf.org Subject: RE: [Simple] Strength of XML validity requirements in SIMPLE docu ments Date: Fri, 17 Sep 2004 14:31:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b I can't agree with a statement that begins "a private extension...". If the schema anticipates extension points (as Pete points out), then the XML will be valid. Saying "SHOULD be valid, because we might extend things willy-nilly without standardization" MUST NOT be allowed. > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: Thursday, September 16, 2004 8:08 AM > To: Jonathan Rosenberg; Pekka Pessi > Cc: Robert Sparks; simple@ietf.org > Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE > documents > > > Please see below... > ----- Original Message ----- > From: "Pekka Pessi" > > > > Jonathan Rosenberg writes: > > >Hmm, its a good question. I think that the vast majority of XML > > >docs produced in the SIP/SIPPING/SIMPLE groups have the same > > >words, and to be honest, I had not given a ton of thought to MUST > > >vs. SHOULD for valid. I can't really think of a reason why it > > >would ever be the right thing to produce a document that is not > > >valid, particularly if the recipient does schema validation. > > > > The presence documents may contain all kind of extensions, which > > may be only meaningful for a single application using the presence > > service. The presence servers or any intermediate nodes (not to > > speak about any innocent watcher) can't really know if the > > documents are valid unless they know the schema for all of > > those extensions. > > > > Like, if composer puts two tuples from two different sources to > > the combined document in the presence server. Both the extensions > > use ID attributes, but how could the composer know which > > attributes have xs:ID type? The following example may be valid, or > > then not, but who is to say without a schema? > > > > > > > xmlns:x="http://example.com/ex/ten/sion" > > entity="pres:john.doe@example.com"> > > open > > > > > > > > > I don't know about the specifics of the presence schema, but > presumably the > original presence schema specifies namespace='##other'/> at some key > points. Hence the document is valid against the original schema. > (Mumbo-jumbo is valid in the schema sense as long as it is > from another > namespace.) Put another way, a document can be valid in the > schema sense, > but still not be semantically correct. > > How validity is established for the extensions is another > issue. This comes > down to versioning. I think this is an area where the > group(s) needs to get > a common understanding on how things should be done. (Schema > is actually > weak in this area! There are ways, but they don't come for > free and they > certainly don't happen by accident!) > > Pete. > -- > ============================================= > Pete Cordell > Tech-Know-Ware > pete(at)tech-know-ware.com > http://www.tech-know-ware.com > http://www.xml2cpp.com - Now Available > +44 1473 635863 > ============================================= > > > > --Pekka > > > > >Robert Sparks wrote: > ... cut ... > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 20 01:01:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12273; Mon, 20 Sep 2004 01:01:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9GP0-0004AW-OY; Mon, 20 Sep 2004 01:07:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9GID-0005Y3-W4; Mon, 20 Sep 2004 01:00:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9GGp-0005DA-UY for simple@megatron.ietf.org; Mon, 20 Sep 2004 00:59:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12142 for ; Mon, 20 Sep 2004 00:59:21 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9GMl-00047Q-Is for simple@ietf.org; Mon, 20 Sep 2004 01:05:42 -0400 Received: from dynamicsoft.com ([63.113.46.29]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8K4x0pl008945; Mon, 20 Sep 2004 00:59:01 -0400 (EDT) Message-ID: <414E637E.7030307@dynamicsoft.com> Date: Mon, 20 Sep 2004 00:58:38 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Pessi Subject: Re: [Simple] NOTIFY without message-body References: <41487517.9070308@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Pekka Pessi wrote: > Hi Jonathan, > > >> If the Content-TYpe is present, and the length is zero, it means >> that the body is of that type but has no information in it. I'll >> note that this is probably illegal, since a PIDF document is >> supposed to be valid/well-formed, and null content doesnt have that >> property. > > >> If the Content-Type is absent and the length is zero, it means that >> there is no body, and the state of the watched resource is >> unchanged. > > > OK. So, if I understood the specs correctly, the notifier can send a > NOTIFY without body at any time. Right. > > Now, let's assume that the subscriber is out of sync with, for > instance, partial presence notifications. How it can ask the server > to send a NOTIFY with full state? It could terminate and recreate the > subscription, but that potentially involve a large number of message. A subscribe refresh is supposed to trigger a state update, for most packages. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 20 01:06:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12690; Mon, 20 Sep 2004 01:06:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9GU2-0004HD-3Y; Mon, 20 Sep 2004 01:13:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9GMj-0006Pr-So; Mon, 20 Sep 2004 01:05:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9GLv-0006FU-9l for simple@megatron.ietf.org; Mon, 20 Sep 2004 01:04:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12521 for ; Mon, 20 Sep 2004 01:04:38 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9GS1-0004EU-5I for simple@ietf.org; Mon, 20 Sep 2004 01:10:57 -0400 Received: from dynamicsoft.com ([63.113.46.29]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8K54Kpl008954; Mon, 20 Sep 2004 01:04:21 -0400 (EDT) Message-ID: <414E64BF.9090007@dynamicsoft.com> Date: Mon, 20 Sep 2004 01:03:59 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] NOTIFY without message-body References: <20040915175938.86053.qmail@web52808.mail.yahoo.com> <41490CAE.70902@dynamicsoft.com> <414A2806.2040009@cisco.com> In-Reply-To: <414A2806.2040009@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: Pekka Pessi , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Jonathan, > > What you suggest is plausible, but I don't recall ever seeing anything > written that discusses the meaning of a Content-Type with an empty body. > > That logic would imply that there is (conceptually) a special content > type for which an empty body is valid and a non-empty body is not, and > that this is a default content-type when the body is empty. I don't see how you would come to this conclusion. There is no default value for Content-Type. > > I believe I have seen stacks that considered the presence of a content > type header invalid if there is no body. At the least there ought to be > something that says this is valid usage. It is written, in RFC 3261, section 20.15: 20.15 Content-Type The Content-Type header field indicates the media type of the message-body sent to the recipient. The "media-type" element is defined in [H3.7]. The Content-Type header field MUST be present if the body is not empty. If the body is empty, and a Content-Type header field is present, it indicates that the body of the specific type has zero length (for example, an empty audio file). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 20 01:21:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13514; Mon, 20 Sep 2004 01:21:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9GiR-0004YP-5l; Mon, 20 Sep 2004 01:27:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9Gb5-0000un-QO; Mon, 20 Sep 2004 01:20:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9GXe-0000Kk-IF for simple@megatron.ietf.org; Mon, 20 Sep 2004 01:16:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13249 for ; Mon, 20 Sep 2004 01:16:45 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9Gdh-0004Ry-I6 for simple@ietf.org; Mon, 20 Sep 2004 01:23:04 -0400 Received: from dynamicsoft.com ([63.113.46.29]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8K5GVpl008961; Mon, 20 Sep 2004 01:16:31 -0400 (EDT) Message-ID: <414E6799.8070509@dynamicsoft.com> Date: Mon, 20 Sep 2004 01:16:09 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Urpalainen Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE documents References: <414735F4.1070302@dynamicsoft.com> <41490131.8030207@dynamicsoft.com> <41493FDC.4000100@nokia.com> In-Reply-To: <41493FDC.4000100@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: Pekka Pessi , Robert Sparks , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit inline. Jari Urpalainen wrote: > ext Jonathan Rosenberg wrote: > >> inline. >> >> Pekka Pessi wrote: >> >>> Jonathan Rosenberg writes: >>> >>>> Hmm, its a good question. I think that the vast majority of XML >>>> docs produced in the SIP/SIPPING/SIMPLE groups have the same >>>> words, and to be honest, I had not given a ton of thought to MUST >>>> vs. SHOULD for valid. I can't really think of a reason why it >>>> would ever be the right thing to produce a document that is not >>>> valid, particularly if the recipient does schema validation. >>> >>> >>> >>> >>> The presence documents may contain all kind of extensions, which >>> may be only meaningful for a single application using the presence >>> service. The presence servers or any intermediate nodes (not to >>> speak about any innocent watcher) can't really know if the >>> documents are valid unless they know the schema for all of >>> those extensions. >>> >>> Like, if composer puts two tuples from two different sources to >>> the combined document in the presence server. Both the extensions >>> use ID attributes, but how could the composer know which >>> attributes have xs:ID type? The following example may be valid, or >>> then not, but who is to say without a schema? >> >> >> >> It depends on how you want to define "valid". If a document has some >> extensions (say, rpid ones), such a document is still valid according >> to just the pidf schema, since it contains well-formed elements from >> another namespace in a place allowed by the schema. >> >> So, when we say "SHOULD be valid", do we mean that all elements in the >> document should be valid according to their defined schemas, or just >> that the document is valid according to the pidf schema? >> >> -Jonathan R. > > > IMO pidf schema requirement is a "MUST" as content-type > application/pidf+xml is defined by that schema. How could you use some > instance document with that content-type if it is not valid ? No, that's not what I'm saying. I'm saying that a document of type application/pidf+xml could be valid against the PIDF schema, but it contains extensions (which are allowed in the pidf schema), and those extensions make use of elements defined in another schema. However, those elements are not valid according to that other schema. In this case, do we consider this document "valid"? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 20 04:07:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08677; Mon, 20 Sep 2004 04:07:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9JIy-0007xX-Ja; Mon, 20 Sep 2004 04:13:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9J9m-0006iO-NH; Mon, 20 Sep 2004 04:04:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9J7D-0006J9-Fe for simple@megatron.ietf.org; Mon, 20 Sep 2004 04:01:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08263 for ; Mon, 20 Sep 2004 04:01:37 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9JDK-0007pV-HR for simple@ietf.org; Mon, 20 Sep 2004 04:07:59 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8K81NL15593; Mon, 20 Sep 2004 11:01:23 +0300 (EET DST) X-Scanned: Mon, 20 Sep 2004 11:01:07 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i8K817Y6015200; Mon, 20 Sep 2004 11:01:07 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00b7q0wE; Mon, 20 Sep 2004 11:01:05 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8K814Y27981; Mon, 20 Sep 2004 11:01:04 +0300 (EET DST) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Sep 2004 11:00:51 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Sep 2004 11:00:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Strength of XML validity requirements in SIMPLE documents Date: Mon, 20 Sep 2004 11:00:50 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B613@esebe056.ntc.nokia.com> Thread-Topic: [Simple] Strength of XML validity requirements in SIMPLE documents Thread-Index: AcSe0fKIe19ta6mKToqESe624ZKgtAAFMj+Q To: , X-OriginalArrivalTime: 20 Sep 2004 08:00:51.0504 (UTC) FILETIME=[F26C6300:01C49EE7] X-Spam-Score: 0.3 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Cc: Pekka.Pessi@nokia.com, RjS@xten.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable I see Jonathan's point here.=20 I think what we need is 2 normative sentences here: The XML document = MUST be valid for the creator and SHOULD be valid for the consumer. It = is a MUST for the creator since there is no reason whatsoever for the = document to be produced and not validated. It is a SHOULD for the = consumer since the XML document may have extensions that are not = understood but are valid according to the base schema. The consumer can = truly validate the XML document if he possesses all schema extensions = required. Regards, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 20.September.2004 08:16 > To: Urpalainen Jari (Nokia-NRC/Helsinki) > Cc: Pessi Pekka (Nokia-NRC/Helsinki); Robert Sparks; simple@ietf.org > Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE > documents >=20 >=20 > inline. >=20 > Jari Urpalainen wrote: >=20 > > ext Jonathan Rosenberg wrote: > >=20 > >> inline. > >> > >> Pekka Pessi wrote: > >> > >>> Jonathan Rosenberg writes: > >>> > >>>> Hmm, its a good question. I think that the vast majority of XML > >>>> docs produced in the SIP/SIPPING/SIMPLE groups have the same > >>>> words, and to be honest, I had not given a ton of thought to MUST > >>>> vs. SHOULD for valid. I can't really think of a reason why it > >>>> would ever be the right thing to produce a document that is not > >>>> valid, particularly if the recipient does schema validation. > >>> > >>> > >>> > >>> > >>> The presence documents may contain all kind of extensions, which > >>> may be only meaningful for a single application using the presence > >>> service. The presence servers or any intermediate nodes (not to > >>> speak about any innocent watcher) can't really know if the > >>> documents are valid unless they know the schema for all of > >>> those extensions. > >>> > >>> Like, if composer puts two tuples from two different sources to > >>> the combined document in the presence server. Both the extensions > >>> use ID attributes, but how could the composer know which > >>> attributes have xs:ID type? The following example may be valid, or > >>> then not, but who is to say without a schema? > >> > >> > >> > >> It depends on how you want to define "valid". If a=20 > document has some=20 > >> extensions (say, rpid ones), such a document is still=20 > valid according=20 > >> to just the pidf schema, since it contains well-formed=20 > elements from=20 > >> another namespace in a place allowed by the schema. > >> > >> So, when we say "SHOULD be valid", do we mean that all=20 > elements in the=20 > >> document should be valid according to their defined=20 > schemas, or just=20 > >> that the document is valid according to the pidf schema? > >> > >> -Jonathan R. > >=20 > >=20 > > IMO pidf schema requirement is a "MUST" as content-type=20 > > application/pidf+xml is defined by that schema. How could=20 > you use some=20 > > instance document with that content-type if it is not valid ?=20 >=20 > No, that's not what I'm saying. >=20 > I'm saying that a document of type application/pidf+xml could=20 > be valid=20 > against the PIDF schema, but it contains extensions (which=20 > are allowed=20 > in the pidf schema), and those extensions make use of=20 > elements defined=20 > in another schema. However, those elements are not valid according to=20 > that other schema. >=20 > In this case, do we consider this document "valid"? >=20 > -Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 20 05:36:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14331; Mon, 20 Sep 2004 05:36:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9KhQ-0001H8-0G; Mon, 20 Sep 2004 05:43:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9KV5-0000Xa-Qu; Mon, 20 Sep 2004 05:30:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9KUs-0000PX-2c for simple@megatron.ietf.org; Mon, 20 Sep 2004 05:30:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13932 for ; Mon, 20 Sep 2004 05:30:07 -0400 (EDT) Received: from cmailm1.svr.pol.co.uk ([195.92.193.18]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9Kb0-00018w-5G for simple@ietf.org; Mon, 20 Sep 2004 05:36:30 -0400 Received: from user-7696.l1.c3.dsl.pol.co.uk ([81.79.30.16] helo=RW) by cmailm1.svr.pol.co.uk with smtp (Exim 4.14) id 1C9KUn-0003VY-Rd; Mon, 20 Sep 2004 10:30:05 +0100 Message-ID: <008c01c49ef4$69d01570$c700a8c0@RW> From: "Pete Cordell" To: , , References: <5816828233DEFA41807A6CFDFDF2343C08B613@esebe056.ntc.nokia.com> Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE documents Date: Mon, 20 Sep 2004 10:27:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit Cc: Pekka.Pessi@nokia.com, RjS@xten.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit I think the statements needs to be something like: The XML document MUST be valid for the creator (no change). The XML document MUST be valid for the consumer according to the perhaps incomplete set of schema copies that it holds (or has access to) that are applicable to the XML document. The wording sucks, but hopefully you can see the intent! Pete. -- ============================================= Pete Cordell Tech-Know-Ware pete(at)tech-know-ware.com http://www.tech-know-ware.com http://www.xml2cpp.com - Now Available +44 1473 635863 ============================================= ----- Original Message ----- From: To: ; Cc: ; ; Sent: Monday, September 20, 2004 9:00 AM Subject: RE: [Simple] Strength of XML validity requirements in SIMPLE documents I see Jonathan's point here. I think what we need is 2 normative sentences here: The XML document MUST be valid for the creator and SHOULD be valid for the consumer. It is a MUST for the creator since there is no reason whatsoever for the document to be produced and not validated. It is a SHOULD for the consumer since the XML document may have extensions that are not understood but are valid according to the base schema. The consumer can truly validate the XML document if he possesses all schema extensions required. Regards, Hisham > -----Original Message----- > From: simple-bounces@ietf.org > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 20.September.2004 08:16 > To: Urpalainen Jari (Nokia-NRC/Helsinki) > Cc: Pessi Pekka (Nokia-NRC/Helsinki); Robert Sparks; simple@ietf.org > Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE > documents > > > inline. > > Jari Urpalainen wrote: > > > ext Jonathan Rosenberg wrote: > > > >> inline. > >> > >> Pekka Pessi wrote: > >> > >>> Jonathan Rosenberg writes: > >>> > >>>> Hmm, its a good question. I think that the vast majority of XML > >>>> docs produced in the SIP/SIPPING/SIMPLE groups have the same > >>>> words, and to be honest, I had not given a ton of thought to MUST > >>>> vs. SHOULD for valid. I can't really think of a reason why it > >>>> would ever be the right thing to produce a document that is not > >>>> valid, particularly if the recipient does schema validation. > >>> > >>> > >>> > >>> > >>> The presence documents may contain all kind of extensions, which > >>> may be only meaningful for a single application using the presence > >>> service. The presence servers or any intermediate nodes (not to > >>> speak about any innocent watcher) can't really know if the > >>> documents are valid unless they know the schema for all of > >>> those extensions. > >>> > >>> Like, if composer puts two tuples from two different sources to > >>> the combined document in the presence server. Both the extensions > >>> use ID attributes, but how could the composer know which > >>> attributes have xs:ID type? The following example may be valid, or > >>> then not, but who is to say without a schema? > >> > >> > >> > >> It depends on how you want to define "valid". If a > document has some > >> extensions (say, rpid ones), such a document is still > valid according > >> to just the pidf schema, since it contains well-formed > elements from > >> another namespace in a place allowed by the schema. > >> > >> So, when we say "SHOULD be valid", do we mean that all > elements in the > >> document should be valid according to their defined > schemas, or just > >> that the document is valid according to the pidf schema? > >> > >> -Jonathan R. > > > > > > IMO pidf schema requirement is a "MUST" as content-type > > application/pidf+xml is defined by that schema. How could > you use some > > instance document with that content-type if it is not valid ? > > No, that's not what I'm saying. > > I'm saying that a document of type application/pidf+xml could > be valid > against the PIDF schema, but it contains extensions (which > are allowed > in the pidf schema), and those extensions make use of > elements defined > in another schema. However, those elements are not valid according to > that other schema. > > In this case, do we consider this document "valid"? > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 20 10:36:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07939; Mon, 20 Sep 2004 10:36:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9PNo-0007Qn-Aw; Mon, 20 Sep 2004 10:43:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9PBV-00073Y-3y; Mon, 20 Sep 2004 10:30:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9P8q-0006EJ-EN for simple@megatron.ietf.org; Mon, 20 Sep 2004 10:27:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07148 for ; Mon, 20 Sep 2004 10:27:42 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9PF0-0007GO-Vd for simple@ietf.org; Mon, 20 Sep 2004 10:34:07 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 20 Sep 2004 07:32:03 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i8KER9bs006757; Mon, 20 Sep 2004 07:27:10 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALR03914; Mon, 20 Sep 2004 10:27:08 -0400 (EDT) Message-ID: <414EE8BC.6030008@cisco.com> Date: Mon, 20 Sep 2004 10:27:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] NOTIFY without message-body References: <20040915175938.86053.qmail@web52808.mail.yahoo.com> <41490CAE.70902@dynamicsoft.com> <414A2806.2040009@cisco.com> <414E64BF.9090007@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Pekka Pessi , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > Paul Kyzivat wrote: > >> Jonathan, >> >> What you suggest is plausible, but I don't recall ever seeing anything >> written that discusses the meaning of a Content-Type with an empty body. >> >> That logic would imply that there is (conceptually) a special content >> type for which an empty body is valid and a non-empty body is not, and >> that this is a default content-type when the body is empty. > > I don't see how you would come to this conclusion. There is no default > value for Content-Type. This is probably just splitting hairs, and not worth discussion. >> I believe I have seen stacks that considered the presence of a content >> type header invalid if there is no body. At the least there ought to >> be something that says this is valid usage. > > > It is written, in RFC 3261, section 20.15: > > 20.15 Content-Type > > The Content-Type header field indicates the media type of the > message-body sent to the recipient. The "media-type" element is > defined in [H3.7]. The Content-Type header field MUST be present if > the body is not empty. If the body is empty, and a Content-Type > header field is present, it indicates that the body of the specific > type has zero length (for example, an empty audio file). OK - I didn't remember that was there. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 20 10:55:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09574; Mon, 20 Sep 2004 10:55:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9Pfw-0007mm-8d; Mon, 20 Sep 2004 11:01:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9PW8-0003zo-Lg; Mon, 20 Sep 2004 10:51:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9PV1-0003jH-CQ for simple@megatron.ietf.org; Mon, 20 Sep 2004 10:50:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09136 for ; Mon, 20 Sep 2004 10:50:37 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9PbB-0007fE-Nd for simple@ietf.org; Mon, 20 Sep 2004 10:57:02 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 20 Sep 2004 07:50:07 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i8KEo3bs024048; Mon, 20 Sep 2004 07:50:04 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALR06089; Mon, 20 Sep 2004 10:50:02 -0400 (EDT) Message-ID: <414EEE1A.6070808@cisco.com> Date: Mon, 20 Sep 2004 10:50:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE documents References: <5816828233DEFA41807A6CFDFDF2343C08B613@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit Cc: Pekka.Pessi@nokia.com, Jari.Urpalainen@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org, RjS@xten.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > I see Jonathan's point here. > > I think what we need is 2 normative sentences here: > The XML document MUST be valid for the creator I think the above can cause problems, depending on how you define "creator". Consider a presence document that is created by a UA and published to a PS. The PS then aggregates the contents of this published document, filters that, and thus creates another presence document that is send out in a NOTIFY. The UA could have used an extension that is unknown to the PS. But IMO the PS should still have the option of including that unknown portion into the document it sends out in the NOTIFY. But then it would be violating this new proposed rule. Imposing this rule *requires* that the PS be aware of any extensions used by any of its sources of presence information. So I think this all needs to be SHOULD level. Also, I agree with Pete's later comment that validity according to PIDF is always a requirement. Paul > and SHOULD be valid for the consumer. It is a MUST for the creator since there is no reason whatsoever for the document to be produced and not validated. It is a SHOULD for the consumer since the XML document may have extensions that are not understood but are valid according to the base schema. The consumer can truly validate the XML document if he possesses all schema extensions required. > > Regards, > Hisham > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org]On Behalf >>Of ext Jonathan Rosenberg >>Sent: 20.September.2004 08:16 >>To: Urpalainen Jari (Nokia-NRC/Helsinki) >>Cc: Pessi Pekka (Nokia-NRC/Helsinki); Robert Sparks; simple@ietf.org >>Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE >>documents >> >> >>inline. >> >>Jari Urpalainen wrote: >> >> >>>ext Jonathan Rosenberg wrote: >>> >>> >>>>inline. >>>> >>>>Pekka Pessi wrote: >>>> >>>> >>>>>Jonathan Rosenberg writes: >>>>> >>>>> >>>>>>Hmm, its a good question. I think that the vast majority of XML >>>>>>docs produced in the SIP/SIPPING/SIMPLE groups have the same >>>>>>words, and to be honest, I had not given a ton of thought to MUST >>>>>>vs. SHOULD for valid. I can't really think of a reason why it >>>>>>would ever be the right thing to produce a document that is not >>>>>>valid, particularly if the recipient does schema validation. >>>>> >>>>> >>>>> >>>>> >>>>>The presence documents may contain all kind of extensions, which >>>>>may be only meaningful for a single application using the presence >>>>>service. The presence servers or any intermediate nodes (not to >>>>>speak about any innocent watcher) can't really know if the >>>>>documents are valid unless they know the schema for all of >>>>>those extensions. >>>>> >>>>>Like, if composer puts two tuples from two different sources to >>>>>the combined document in the presence server. Both the extensions >>>>>use ID attributes, but how could the composer know which >>>>>attributes have xs:ID type? The following example may be valid, or >>>>>then not, but who is to say without a schema? >>>> >>>> >>>> >>>>It depends on how you want to define "valid". If a >>> >>document has some >> >>>>extensions (say, rpid ones), such a document is still >>> >>valid according >> >>>>to just the pidf schema, since it contains well-formed >>> >>elements from >> >>>>another namespace in a place allowed by the schema. >>>> >>>>So, when we say "SHOULD be valid", do we mean that all >>> >>elements in the >> >>>>document should be valid according to their defined >>> >>schemas, or just >> >>>>that the document is valid according to the pidf schema? >>>> >>>>-Jonathan R. >>> >>> >>>IMO pidf schema requirement is a "MUST" as content-type >>>application/pidf+xml is defined by that schema. How could >> >>you use some >> >>>instance document with that content-type if it is not valid ? >> >>No, that's not what I'm saying. >> >>I'm saying that a document of type application/pidf+xml could >>be valid >>against the PIDF schema, but it contains extensions (which >>are allowed >>in the pidf schema), and those extensions make use of >>elements defined >>in another schema. However, those elements are not valid according to >>that other schema. >> >>In this case, do we consider this document "valid"? >> >>-Jonathan R. >> >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 20 12:53:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20216; Mon, 20 Sep 2004 12:53:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9RWW-00024M-1b; Mon, 20 Sep 2004 13:00:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9RJo-0005wB-5j; Mon, 20 Sep 2004 12:47:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9R7B-00029O-7s for simple@megatron.ietf.org; Mon, 20 Sep 2004 12:34:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18554 for ; Mon, 20 Sep 2004 12:34:06 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9RDD-0001cN-4A for simple@ietf.org; Mon, 20 Sep 2004 12:40:33 -0400 Received: from dynamicsoft.com ([63.113.46.120]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8KGVspl009244; Mon, 20 Sep 2004 12:31:54 -0400 (EDT) Message-ID: <414F05E5.70604@dynamicsoft.com> Date: Mon, 20 Sep 2004 12:31:33 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE documents References: <5816828233DEFA41807A6CFDFDF2343C08B613@esebe056.ntc.nokia.com> <414EEE1A.6070808@cisco.com> In-Reply-To: <414EEE1A.6070808@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Pekka.Pessi@nokia.com, Jari.Urpalainen@nokia.com, simple@ietf.org, RjS@xten.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > > > hisham.khartabil@nokia.com wrote: > >> I see Jonathan's point here. >> I think what we need is 2 normative sentences here: > > > The XML document MUST be valid for the creator > > I think the above can cause problems, depending on how you define > "creator". > > Consider a presence document that is created by a UA and published to a > PS. The PS then aggregates the contents of this published document, > filters that, and thus creates another presence document that is send > out in a NOTIFY. > > The UA could have used an extension that is unknown to the PS. But IMO > the PS should still have the option of including that unknown portion > into the document it sends out in the NOTIFY. But then it would be > violating this new proposed rule. Right. It can be easier to define these validity rules in the context of a specific protocol usage, and in the above case we could except a presence server from needing to generate valid documents. Those kinds of rules belong in protocol documents, not in the specifications of the document formats themselves. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 21 04:04:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21535; Tue, 21 Sep 2004 04:04:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9fk4-0005Vc-Jk; Tue, 21 Sep 2004 04:11:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9fbr-0007Am-2w; Tue, 21 Sep 2004 04:02:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9fXS-0006L0-Sf for simple@megatron.ietf.org; Tue, 21 Sep 2004 03:58:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21136 for ; Tue, 21 Sep 2004 03:58:13 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9fdm-0005QL-0Y for simple@ietf.org; Tue, 21 Sep 2004 04:04:47 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8L7wBL07760 for ; Tue, 21 Sep 2004 10:58:11 +0300 (EET DST) X-Scanned: Tue, 21 Sep 2004 10:58:03 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i8L7w3DL003123 for ; Tue, 21 Sep 2004 10:58:03 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00Wbynxr; Tue, 21 Sep 2004 10:58:03 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8L7vwS12551 for ; Tue, 21 Sep 2004 10:57:58 +0300 (EET DST) Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 21 Sep 2004 10:57:57 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 21 Sep 2004 10:57:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] FW: CPCP Issue 37: Generic privileges solution Date: Tue, 21 Sep 2004 10:57:56 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B621@esebe056.ntc.nokia.com> Thread-Topic: CPCP Issue 37: Generic privileges solution Thread-Index: AcSZl/3YES5bsnqwSe+ryN/uBrPDqgAAL7cAAYX55dA= To: X-OriginalArrivalTime: 21 Sep 2004 07:57:57.0009 (UTC) FILETIME=[B4D45010:01C49FB0] X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable It would be great if I can get people's gut feeling on this. Thanks, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext hisham.khartabil@nokia.com > Sent: 13.September.2004 16:52 > To: simple@ietf.org > Subject: [Simple] FW: CPCP Issue 37: Generic privileges solution >=20 >=20 > The draft can be found at: > http://www.imsbook.com/hisham/draft-ietf-xcon-conference-polic > y-privileges-00.txt >=20 > SIMPLE WG comments are being sorted on this issue presented below. >=20 > Thanks, > Hisham >=20 > > -----Original Message----- > > From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)=20 > > Sent: 13.September.2004 16:46 > > To: 'xcon@ietf.org' > > Subject: CPCP Issue 37: Generic privileges solution > >=20 > >=20 > > This issue affects=20 > > draft-ietf-xcon-conference-policy-privileges-00.txt. > >=20 > > The schema in this draft is generic and can be used for any=20 > > XML document that carries user information and resides on a=20 > > server. It is useful especially for XCAP. > >=20 > > I have been toying with the idea of extracting the schema=20 > > into a separate draft and submitting that in SIMPLE. XCON can=20 > > then use that draft and customise it for conferencing needs.=20 > > By customising it, I mean defining the actions and=20 > > transformations that grant the conferencing specific=20 > > privileges to users. > >=20 > > This solution uses common policy as well where the conditions=20 > > carry the document URI and the identity of users and the=20 > > actions carry the privileges (read/modify certain parts of=20 > > the conference policy). > >=20 > > BTW, the draft defines a sematic approach as agreed in San Diego. > >=20 > > So, what do people think of that? > >=20 > > I'll forward this email to SIMPLE for comments. > >=20 > > Regards, > > Hisham > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 21 06:24:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00935; Tue, 21 Sep 2004 06:24:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9hux-0007uA-4z; Tue, 21 Sep 2004 06:30:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9hnE-0003jW-QL; Tue, 21 Sep 2004 06:22:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9hjR-00031T-1r for simple@megatron.ietf.org; Tue, 21 Sep 2004 06:18:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00543 for ; Tue, 21 Sep 2004 06:18:42 -0400 (EDT) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9hpm-0007oq-7P for simple@ietf.org; Tue, 21 Sep 2004 06:25:19 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8LAIRL17088; Tue, 21 Sep 2004 13:18:27 +0300 (EET DST) X-Scanned: Tue, 21 Sep 2004 13:18:03 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i8LAI34p016537; Tue, 21 Sep 2004 13:18:03 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00Qw0pz7; Tue, 21 Sep 2004 13:18:01 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8LAHuS11942; Tue, 21 Sep 2004 13:17:56 +0300 (EET DST) Received: from [172.21.42.160] ([172.21.42.160]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 21 Sep 2004 13:17:49 +0300 Message-ID: <414FFFCF.8020007@nokia.com> Date: Tue, 21 Sep 2004 13:17:51 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: ben@nostrum.com, rohan@cisco.com, fluffy@cisco.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Sep 2004 10:17:49.0087 (UTC) FILETIME=[3EE5CAF0:01C49FC4] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: SIMPLE mailing list Subject: [Simple] MSRP URLs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Hi: A few comments about section 5 of the MSRP draft: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-08.txt 1) The draft should describe the type of resources that are identified by an MSRP URL. So I would suggest to add an introductory paragraph at the beginning of section 5 that says something on the following lines: The MSRP and MSRPS URL schemes are used to designate a session of instant messages at a particular host computer. Question: is this definition also applicable to relays? 2) RFC 2396 is under revision, nowadays draft-fielding-uri-rfc2396bis-06.txt. I am not sure if you still want to refer to RFC 2396 or the revision of it. I guess this depends of which draft makes it first to the IESG. Among other things, in case you want to refer to rfc2396bis, this draft has removed the definition of "hostport". Now it is just "host [: port]" 3) The current definition of an MSRP URL includes a "resource" part, when actually it is a "path" or "session-id", because a "resource" is the the whole MSRP URL, including the URI scheme and the hostname. So I would suggest to replace the current definition: MSRP_urls = msrp-scheme "://" [userinfo "@"] hostport ["/" resource] ";" transport resource = 1*unreserved with this other one: MSRP_urls = msrp-scheme "://" [userinfo "@"] hostport ["/" path] ";" transport resource = 1*unreserved 4) According to rfc2396bis, "unrerved" is defined as: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" On purpose "unreserved" does not include "sub-delims", which is defined as: sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" I guess it is OK for MSRP that the path is formed of unreserved characters, not including sub-delims. But I would like to point this out in case someone feels the path needs to include sub-delims. 5) I find a contradiction that we, on one hand, allow to have a "userinfo" part in the MSRP URL including a reference to RFC 2396, and on the other hand we restrict the "userinfo" definition in RFC 23964 to unreserved characters. RFC 2396 (and 2396bis) allow to have escaped characters in the userinfo. However, MSRP does not, but still refers to 2396 for the definition of userinfo. So, if the "userinfo" defined in the MSRP URL is different from (or a subset of) the "userinfo" defined in RFC 2396, then I would suggest to change the name (perhaps "unescaped-userinfo"), and avoid the reference to RFC 2396. 6) Section 5.1 reads on the second bullet point: 2. If the hostpart contains an eplicit IP address, and/or port, these are compared numerically. Otherwise, hostpart is compared as a case insensitive character string. I was wondering in the how to treat zeros in either IPv4 or IPv6 (IPv6 uses this quite oftenly). The missleading word is "numerically", since I am not sure if the "::" should be normalized by adding trailing and leading zeros or not. Is it the intention that the following two URLs are equivalent and MSRP endpoints should detect it? msrp://[1080:0:0:0:8:800:200C:417A]/aodisfa;tcp msrp://[1080::8:800:200C:417A]/aodisfa;tcp A clarification should be written. Regards, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 21 07:49:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06572; Tue, 21 Sep 2004 07:49:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9jFl-0000z1-Mh; Tue, 21 Sep 2004 07:56:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9j8N-0007Wg-BG; Tue, 21 Sep 2004 07:48:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9j4t-0006hL-AA for simple@megatron.ietf.org; Tue, 21 Sep 2004 07:45:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06361 for ; Tue, 21 Sep 2004 07:44:58 -0400 (EDT) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9jBF-0000vK-8S for simple@ietf.org; Tue, 21 Sep 2004 07:51:33 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8LBiqL28443; Tue, 21 Sep 2004 14:44:52 +0300 (EET DST) X-Scanned: Tue, 21 Sep 2004 14:44:31 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i8LBiVuD011954; Tue, 21 Sep 2004 14:44:31 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00A9GtyO; Tue, 21 Sep 2004 14:44:28 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8LBiRY01680; Tue, 21 Sep 2004 14:44:27 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 21 Sep 2004 14:44:18 +0300 Received: from agni.research.nokia.com (agni.research.nokia.com [172.21.40.24]) by kusti.research.nokia.com (Postfix) with ESMTP id 719A293B6A; Tue, 21 Sep 2004 14:44:18 +0300 (EEST) Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i8KBZap1017020; Mon, 20 Sep 2004 14:35:36 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i8KBZWAM017019; Mon, 20 Sep 2004 14:35:32 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Jonathan Rosenberg Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE documents X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <414E6799.8070509@dynamicsoft.com> (Jonathan Rosenberg's message of "Mon, 20 Sep 2004 01:16:09 -0400") References: <414735F4.1070302@dynamicsoft.com> <41490131.8030207@dynamicsoft.com> <41493FDC.4000100@nokia.com> <414E6799.8070509@dynamicsoft.com> Date: Mon, 20 Sep 2004 14:35:32 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 21 Sep 2004 11:44:18.0541 (UTC) FILETIME=[540DA1D0:01C49FD0] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Pekka Pessi , Jari Urpalainen , simple@ietf.org, Robert Sparks X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Jonathan Rosenberg writes: >I'm saying that a document of type application/pidf+xml could be valid >against the PIDF schema, but it contains extensions (which are allowed in >the pidf schema), and those extensions make use of elements defined in >another schema. However, those elements are not valid according to that >other schema. >In this case, do we consider this document "valid"? Term valid has at least three different senses with the XML: 1) W3C defines that an XML document is valid when it has a DTD and the document complies with the constraints set forth in DTD. That is not what we want. No for presence, no "MUST be valid", please. (When RFC 3863 says that the application/pidf+xml document MUST be well-formed and SHOULD be valid, I guess it just says that extensions are allowed, even if they are not shown in the DTD.) 2) XML schema specification uses a bit different terminology. Schemas don't specify documents, but trees (item and all its descendants). You can assess validity of a particular tree, for instance, all the XML stuff within element. The validator can also skip certain elements (like the wildcard elements used for extending pidf). So, validator can return different results: tree and items within it are fully validated, partially validated, or not validated at all. Also each, item within the tree are valid or invalid or their validity is not known. I'd say that the XML document is schema-valid if its root element is fully validated and it and all its descendants are valid. This is not the official definition, however. This is unfeasible for the intermediate nodes (or processes), too. Unless the node knows the schema (and semantics) of all the extensions, it cannot assess the validity of composed or filtered documents. I think filtering and composing is precisely the things that we want to do in the server nodes. I can also imagine some applications that would just use existing presence service, just add their non-standard application-specific status in the published presence document. Now imagine two of those applications running on the same node. 3) Beside validity assessment, XML schema specification has the concept of "local schema-validity", too: I must admit that I don't fully understand what this means, but I have a good hunch that it is what most of us want. ;) A element or attribute is valid if it satisfies the constraints set by the XML schema. So, element is valid, if it contains entity attribute, zero or more elements, then zero or more elements and after then something wildcarded stuff (I guess that is anything else but pidf-namespace stuff). I don't understand how the datatype checking of evil types like xs:ID or xs:IDREF is done when the "local schema-validity" is determined. I *guess* that ID/IDREF attribute in tuple is valid if its value is syntactically correct. Like id="_123" is valid but, id="123" is not. No check for all id's within a document/item and all of its descendats is required. So, if we have a application/pidf+xml document, we can simply say that it MUST conform to its schema and other requirements set forth in RFC 3863. If we want to be more verbose, we could say that the root node in the document MUST be partially or fully validated and none of the validated nodes MUST NOT be invalid. Or we could invent our own term and say that documents MUST be locally-schema-valid with the schema XXX. --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 21 09:15:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12456; Tue, 21 Sep 2004 09:15:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9kaR-0002fM-4K; Tue, 21 Sep 2004 09:21:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9kPF-0000NG-5O; Tue, 21 Sep 2004 09:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9kFb-0006CD-EM for simple@megatron.ietf.org; Tue, 21 Sep 2004 09:00:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10997 for ; Tue, 21 Sep 2004 09:00:06 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9kLx-0002MF-BF for simple@ietf.org; Tue, 21 Sep 2004 09:06:42 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8LD03122165 for ; Tue, 21 Sep 2004 16:00:03 +0300 (EET DST) X-Scanned: Tue, 21 Sep 2004 15:59:05 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i8LCx53T012990 for ; Tue, 21 Sep 2004 15:59:05 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00N4YDRg; Tue, 21 Sep 2004 15:59:03 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8LCwvS26780 for ; Tue, 21 Sep 2004 15:58:57 +0300 (EET DST) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 21 Sep 2004 15:58:57 +0300 Received: from esebe052.NOE.Nokia.com ([172.21.138.217]) by esebe024.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 21 Sep 2004 15:58:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Sep 2004 15:58:57 +0300 Message-ID: Thread-Topic: [Simple] Strength of XML validity requirements in SIMPLE documents Thread-Index: AcSf0aKoUIcYF5LHSsW15CqiiyAtxgABMwsA To: X-OriginalArrivalTime: 21 Sep 2004 12:58:57.0531 (UTC) FILETIME=[C1BD44B0:01C49FDA] X-Spam-Score: 0.3 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Subject: [Simple] Scope of XCAP PIDF manipulation wrt. Presence Data Model X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Hi all, The approach presented in Data Model for Presence = (http://www.ietf.org/internet-drafts/draft-rosenberg-simple-presence-data= -model-00.txt) has been in principle approved in SIMPLE WG, but there = are still some open issues on details. One of them concerns the scope of = XCAP application usage for PIDF manipulation = (http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pidf-manipula= tion-usage-01.txt). The Data Model draft has the following text in = Chapter 10:=20 One of the source of confusion around the XCAP manipulation of PIDF [17] is that it was unclear as to why one would use it as opposed to PUBLISH. The presence data model presented here sheds some light on that. PUBLISH is appropriate for communicating information about services and devices. PUBLISH is designed for the model where there can be more than one such source (as there is for devices and servcies), and where such state is soft-state (as it should be for devices and services). However, presentity state is not clearly soft-state, and the model here clearly indicates that each presence document can have a single presentity element. Thus, it might make sense to change the pidf-manipulation spec to only allow setting of presentity tuples. Now, that doesnt forbid a source from trying to PUBLISH presentity information, but there is clearly a need for a hard-state approach for setting presentity information. The concrete issue here is whether XCAP PIDF manipulation should be = restricted to setting only presentity tuple, i.e. not allow the setting = of service tuples or device information. My opinion is that we should not make this kind of restriction.=20 There is at least one use case where "hard state" service tuples make a = lot of sense, and that is service tuples for "persistent" services such = as e-mail, SMS, MMS or voicemail. These communication means are = available for the sender even if the recipient is not on-line wrt. that = service, since there is a network-based "inbox" taking care of them. = XCAP PIDF manipulation is a better way to describe this kind "off-line" = state for such services rather than SIP PUBLISH. (BTW, I believe we = should define some new status attribute to this kind of services to = clearly indicate the difference between "MMS available but no device = on-line" vs. "MMS available with a device on-line" etc. Or probably the = standardization fora responsible for e.g. MMS can do that.) What might be a useful specification is to say that in a typical = scenario information derived from SIP PUBLISH takes presedence over the = information derived from XCAP. But that is already in the territory of = specifying the composer policy, which I think is a separate effort from = the data model of XCAP PIDF manipulation drafts. So my proposal is basically to keep the XCAP PIDF manipulation draft as = it is at the moment, and not make any restricting statements about its = use in the Data Model either. Are there other opinions on this topic? Regards, Markus =20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 21 12:02:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26122; Tue, 21 Sep 2004 12:02:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9nCu-0005eq-4O; Tue, 21 Sep 2004 12:09:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9mus-0006d0-N8; Tue, 21 Sep 2004 11:50:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9mnx-0004pu-Rl for simple@megatron.ietf.org; Tue, 21 Sep 2004 11:43:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24123 for ; Tue, 21 Sep 2004 11:43:43 -0400 (EDT) Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9muM-0005Cv-5e for simple@ietf.org; Tue, 21 Sep 2004 11:50:22 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i8LFf5lF013608; Tue, 21 Sep 2004 10:41:05 -0500 (CDT) Message-ID: <41504B90.7060307@alcatel.com> Date: Tue, 21 Sep 2004 10:41:04 -0500 From: Alex Audu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] NOTIFY without message-body References: <20040915175938.86053.qmail@web52808.mail.yahoo.com> <41490CAE.70902@dynamicsoft.com> <414A2806.2040009@cisco.com> <414E64BF.9090007@dynamicsoft.com> <414EE8BC.6030008@cisco.com> In-Reply-To: <414EE8BC.6030008@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: Pekka Pessi , Jonathan Rosenberg , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alex.audu@alcatel.com List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Hi Jonathan, Paul, According to the following, rfc 2045 defines a default content type of text/plain; charset=us-ascii Cheers, Alex. =========================================================================== RFC 2045 Internet Message Bodies November 1996 5.2. Content-Type Defaults Default RFC 822 messages without a MIME Content-Type header are taken by this protocol to be plain text in the US-ASCII character set, which can be explicitly specified as: Content-type: text/plain; charset=us-ascii This default is assumed if no Content-Type header field is specified. It is also recommend that this default be assumed when a syntactically invalid Content-Type header field is encountered. In the presence of a MIME-Version header field and the absence of any Content-Type header field, a receiving User Agent can also assume that plain US-ASCII text was the sender's intent. Plain US-ASCII text may still be assumed in the absence of a MIME-Version or the presence of an syntactically invalid Content-Type header field, but the sender's intent might have been otherwise. ==================================================================== Paul Kyzivat wrote: > > > Jonathan Rosenberg wrote: > >> >> >> Paul Kyzivat wrote: >> >>> Jonathan, >>> >>> What you suggest is plausible, but I don't recall ever seeing >>> anything written that discusses the meaning of a Content-Type with >>> an empty body. >>> >>> That logic would imply that there is (conceptually) a special >>> content type for which an empty body is valid and a non-empty body >>> is not, and that this is a default content-type when the body is empty. >> >> >> I don't see how you would come to this conclusion. There is no >> default value for Content-Type. > > > This is probably just splitting hairs, and not worth discussion. > >>> I believe I have seen stacks that considered the presence of a >>> content type header invalid if there is no body. At the least there >>> ought to be something that says this is valid usage. >> >> >> >> It is written, in RFC 3261, section 20.15: >> >> 20.15 Content-Type >> >> The Content-Type header field indicates the media type of the >> message-body sent to the recipient. The "media-type" element is >> defined in [H3.7]. The Content-Type header field MUST be present if >> the body is not empty. If the body is empty, and a Content-Type >> header field is present, it indicates that the body of the specific >> type has zero length (for example, an empty audio file). > > > OK - I didn't remember that was there. > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 21 14:34:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08487; Tue, 21 Sep 2004 14:34:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9pZa-0000YF-Fy; Tue, 21 Sep 2004 14:41:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9pOt-0004US-8R; Tue, 21 Sep 2004 14:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9pJ4-0003gX-36 for simple@megatron.ietf.org; Tue, 21 Sep 2004 14:24:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07692 for ; Tue, 21 Sep 2004 14:24:00 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9pPS-0000Kj-Lq for simple@ietf.org; Tue, 21 Sep 2004 14:30:40 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 Sep 2004 11:25:33 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8LINNSI019639; Tue, 21 Sep 2004 11:23:24 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALS37604; Tue, 21 Sep 2004 14:23:25 -0400 (EDT) Message-ID: <4150719D.4040407@cisco.com> Date: Tue, 21 Sep 2004 14:23:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alex.audu@alcatel.com Subject: Re: [Simple] NOTIFY without message-body References: <20040915175938.86053.qmail@web52808.mail.yahoo.com> <41490CAE.70902@dynamicsoft.com> <414A2806.2040009@cisco.com> <414E64BF.9090007@dynamicsoft.com> <414EE8BC.6030008@cisco.com> <41504B90.7060307@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Cc: Pekka Pessi , Jonathan Rosenberg , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Alex Audu wrote: > Hi Jonathan, Paul, > > According to the following, rfc 2045 defines a default content type of > text/plain; charset=us-ascii Well, if we assume the same applies to SIP (not necessarily the case, but plausible), then in the absence of any Content- headers: - the Content-Type would default to 'text/plain' - the Content-Disposition would default to 'render' So it will amount to a request to render a null string of text. If this is applied to NOTIFY, it *could* result in a 415 response. Seems like the right thing to do would be for each event type where this can happen to define the null body that is meaningful. Either explicitly note a null body of type text/plain, or else define the relevant mime type to include a null body. Paul > Cheers, > Alex. > > =========================================================================== > RFC 2045 Internet Message Bodies November 1996 > > > 5.2. Content-Type Defaults > > Default RFC 822 messages without a MIME Content-Type header are taken > by this protocol to be plain text in the US-ASCII character set, > which can be explicitly specified as: > > Content-type: text/plain; charset=us-ascii > > This default is assumed if no Content-Type header field is specified. > It is also recommend that this default be assumed when a > syntactically invalid Content-Type header field is encountered. In > the presence of a MIME-Version header field and the absence of any > Content-Type header field, a receiving User Agent can also assume > that plain US-ASCII text was the sender's intent. Plain US-ASCII > text may still be assumed in the absence of a MIME-Version or the > presence of an syntactically invalid Content-Type header field, but > the sender's intent might have been otherwise. > > ==================================================================== > > Paul Kyzivat wrote: > >> >> >> Jonathan Rosenberg wrote: >> >>> >>> >>> Paul Kyzivat wrote: >>> >>>> Jonathan, >>>> >>>> What you suggest is plausible, but I don't recall ever seeing >>>> anything written that discusses the meaning of a Content-Type with >>>> an empty body. >>>> >>>> That logic would imply that there is (conceptually) a special >>>> content type for which an empty body is valid and a non-empty body >>>> is not, and that this is a default content-type when the body is empty. >>> >>> >>> >>> I don't see how you would come to this conclusion. There is no >>> default value for Content-Type. >> >> >> >> This is probably just splitting hairs, and not worth discussion. >> >>>> I believe I have seen stacks that considered the presence of a >>>> content type header invalid if there is no body. At the least there >>>> ought to be something that says this is valid usage. >>> >>> >>> >>> >>> It is written, in RFC 3261, section 20.15: >>> >>> 20.15 Content-Type >>> >>> The Content-Type header field indicates the media type of the >>> message-body sent to the recipient. The "media-type" element is >>> defined in [H3.7]. The Content-Type header field MUST be present if >>> the body is not empty. If the body is empty, and a Content-Type >>> header field is present, it indicates that the body of the specific >>> type has zero length (for example, an empty audio file). >> >> >> >> OK - I didn't remember that was there. >> >> Paul >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 21 22:34:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22802; Tue, 21 Sep 2004 22:34:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9x4I-0003jn-Hz; Tue, 21 Sep 2004 22:41:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9wwd-0004zM-LQ; Tue, 21 Sep 2004 22:33:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9wtR-00045x-Ee for simple@megatron.ietf.org; Tue, 21 Sep 2004 22:30:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22551 for ; Tue, 21 Sep 2004 22:30:03 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9wzv-0003fG-Jo for simple@ietf.org; Tue, 21 Sep 2004 22:36:48 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 21 Sep 2004 19:31:42 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8M2TRwp011066; Tue, 21 Sep 2004 19:29:28 -0700 (PDT) Received: from [10.0.1.3] (sjc-vpn4-1258.cisco.com [10.21.84.233]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL21961; Tue, 21 Sep 2004 19:29:27 -0700 (PDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Tue, 21 Sep 2004 11:41:50 -0700 Subject: Re: [Simple] MSRP Security Review: RFC3862 Application Considerations From: Cullen Jennings To: , Paul H Kyzivat Message-ID: In-Reply-To: <5816828233DEFA41807A6CFDFDF2343C08B5AA@esebe056.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: 7bit Seem to me that multiple To, Subject, Foo etc in CPIM is not an issues for MSRP - MSRP caries CPIM - headers in CPIM mean what CPIM says they mean. My vague read of 3862 is that there can me one From , multiple To, multiple cc, one DateTime, and is though it is unclear on Subject, I would read it as only one Subject since the things that are multiple it explicitly mentions as such. On 9/10/04 8:55 AM, "hisham.khartabil@nokia.com" wrote: > > >> -----Original Message----- >> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 10.September.2004 16:26 >> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >> Cc: ben@nostrum.com; simple@ietf.org >> Subject: Re: [Simple] MSRP Security Review: RFC3862 Application >> Considerations >> >> >> Hisham, >> >> I agree with most of your comments, but I question the logic >> of multiple >> Subject headers. What does this mean? Is the actual subject the >> catenation of the contents of all the Subject headers? Should >> they have >> between then when displayed? Or are they to be treated as >> alternatives, such as the same subject represented in >> different languages? > > That's what I had in mind. > > /Hisham > >> >> I believe 3261 only allows one Subject header. I don't know >> about email, >> but by common usage I don't think it would work well if there >> was more >> than one. >> >> Paul >> >> hisham.khartabil@nokia.com wrote: >>> >>>> -----Original Message----- >>>> From: simple-bounces@ietf.org >>>> [mailto:simple-bounces@ietf.org]On Behalf >>>> Of ext Ben Campbell >>>> Sent: 10.September.2004 05:22 >>>> To: Simple WG >>>> Subject: [Simple] MSRP Security Review: RFC3862 Application >>>> Considerations >>>> >>>> >>>> Hi, >>>> >>>> Sam's security review pointed out that we had not handled the >>>> application considerations required by RFC3862 on all applications >>>> using the message/cpim MIME type. Here is a first cut at those >>>> considerations for discussion (quoted text from RFC3862) >>>> >>>> >>>>> Applications using this specification must also specify: >>>>> >>>>> o all headers that must be recognized by implementations of the >>>>> application >>>> >>>> All MSRP endpoints MUST recognize the From, To, DateTime, >> and Require >>>> headers as defined in RFC3862. Such applications SHOULD >> recognize the >>>> CC header, and MAY recognize the Subject header. Any MSRP >> application >>>> that recognizes any message/cpim header MUST understand the >> NS (name >>>> space) header. >>>> >>>> >>>>> o any headers that must be present in all messages >>>> >>>> created by that >>>> >>>>> application. >>>> >>>> All message/cpim body parts send by an MSRP endpoint MUST >> include the >>>> From and To headers. If the message/cpim body part is >>>> protected using >>>> S/MIME, then it SHOULD also include the DateTime header. >>>> >>>> >>>>> o any headers that may appear more than once in a >>>> >>>> message, and how >>>> >>>>> they are to be interpreted (e.g., how to interpret multiple >>>>> 'Subject:' headers with different language parameter values). >>>>> >>>> >>>> Message/cpim headers defined in RFC 3862, with the exception >>>> of the NS >>>> header, MUST NOT occur more than once in a given message/cpim >>>> body part >>>> in an MSRP message. The Require header MAY include multiple >>>> values. The >>>> NS header MAY occur zero or more times, depending on how many name >>>> spaces are being referenced. >>>> >>>> Extension headers MAY occur more than once, depending on the >>>> definition >>>> of such headers. >>> >>> >>> The To-header field should not be limited to 1, nor should >> the CC field. This could be used in the future for, what is >> commonly referred to as, whispering or private messages >> within a conference. >>> >>> Also, the subject header might appear multiple times. I >> would say we limit the from-header to one and no limit on the rest. >>> >>> Regards, >>> Hisham >>> >>> >>>>> o Security mechanisms and crytography schemes to be >>>> >>>> used with the >>>> >>>>> application, including any mandatory-to-implement security >>>>> provisions. >>>> >>>> [Ben: I _think_ we are covering this in general--do we need to >>>> explicitly relate such mechanisms to message/cpim?] >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 22 03:51:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10638; Wed, 22 Sep 2004 03:51:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA21W-0000Tn-2Y; Wed, 22 Sep 2004 03:58:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA1tj-0001zR-Rp; Wed, 22 Sep 2004 03:50:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA1rK-0001RE-Av for simple@megatron.ietf.org; Wed, 22 Sep 2004 03:48:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10378 for ; Wed, 22 Sep 2004 03:48:12 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA1xr-0000Qa-8P for simple@ietf.org; Wed, 22 Sep 2004 03:54:59 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8M7lvL23985; Wed, 22 Sep 2004 10:47:57 +0300 (EET DST) X-Scanned: Wed, 22 Sep 2004 10:47:29 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i8M7lTnH023145; Wed, 22 Sep 2004 10:47:29 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00r4Jn0X; Wed, 22 Sep 2004 10:47:19 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8M7lDY01166; Wed, 22 Sep 2004 10:47:13 +0300 (EET DST) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 22 Sep 2004 10:47:12 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 22 Sep 2004 10:47:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] NOTIFY without message-body Date: Wed, 22 Sep 2004 10:47:11 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B62A@esebe056.ntc.nokia.com> Thread-Topic: [Simple] NOTIFY without message-body Thread-Index: AcSez+nUBLPmsaScThq2EWNeYgvibwBp3d4g To: , X-OriginalArrivalTime: 22 Sep 2004 07:47:11.0221 (UTC) FILETIME=[5E52A250:01C4A078] X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: Pekka.Pessi@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 20.September.2004 08:04 > To: Paul Kyzivat > Cc: Pessi Pekka (Nokia-NRC/Helsinki); simple@ietf.org > Subject: Re: [Simple] NOTIFY without message-body >=20 >=20 >=20 >=20 > Paul Kyzivat wrote: >=20 > > Jonathan, > >=20 > > What you suggest is plausible, but I don't recall ever=20 > seeing anything=20 > > written that discusses the meaning of a Content-Type with=20 > an empty body. > >=20 > > That logic would imply that there is (conceptually) a=20 > special content=20 > > type for which an empty body is valid and a non-empty body=20 > is not, and=20 > > that this is a default content-type when the body is empty. >=20 > I don't see how you would come to this conclusion. There is=20 > no default=20 > value for Content-Type. I agree here. Also, the presence of Content-* header does not mean there = is a body. Take for example Content-Length. Many implementations set = that to 0. This could be 2 things: 1. There is no body 2. There is a body, but it has a length of 0. If the interperetation is 2, then content-type needs to have default. We = have so have assumed that content-length: 0 means no body (ie. 1 above). >=20 >=20 >=20 > >=20 > > I believe I have seen stacks that considered the presence=20 > of a content=20 > > type header invalid if there is no body. At the least there=20 > ought to be=20 > > something that says this is valid usage. >=20 > It is written, in RFC 3261, section 20.15: >=20 > 20.15 Content-Type >=20 > The Content-Type header field indicates the media type of the > message-body sent to the recipient. The "media-type" element is > defined in [H3.7]. The Content-Type header field MUST be=20 > present if > the body is not empty. If the body is empty, and a Content-Type > header field is present, it indicates that the body of=20 > the specific > type has zero length (for example, an empty audio file). This may result in a 400 response being returned for, say, XML bodies = since they are not valid (actually, it is unclear what the exact SIP = error response for a malformed body should be. This was an issue at the = last SIPit). Regards, Hisham >=20 >=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 22 05:00:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14671; Wed, 22 Sep 2004 05:00:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA36D-0001uk-Bk; Wed, 22 Sep 2004 05:07:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA2wX-0005ay-9E; Wed, 22 Sep 2004 04:57:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA2to-0004zw-Nz for simple@megatron.ietf.org; Wed, 22 Sep 2004 04:54:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14445 for ; Wed, 22 Sep 2004 04:54:49 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA30M-0001pd-0f for simple@ietf.org; Wed, 22 Sep 2004 05:01:38 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8M8siL11366; Wed, 22 Sep 2004 11:54:44 +0300 (EET DST) X-Scanned: Wed, 22 Sep 2004 11:54:32 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i8M8sW0N021368; Wed, 22 Sep 2004 11:54:32 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00kFJghs; Wed, 22 Sep 2004 11:54:29 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8M8s9S22179; Wed, 22 Sep 2004 11:54:09 +0300 (EET DST) Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 22 Sep 2004 11:54:06 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 22 Sep 2004 11:54:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Strength of XML validity requirements in SIMPLE documents Date: Wed, 22 Sep 2004 11:54:06 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B62E@esebe056.ntc.nokia.com> Thread-Topic: [Simple] Strength of XML validity requirements in SIMPLE documents Thread-Index: AcSf0aLni2Db7fiBQpqL4QzLKHda8wArclWA To: , X-OriginalArrivalTime: 22 Sep 2004 08:54:07.0619 (UTC) FILETIME=[B8485530:01C4A081] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable Cc: Pekka.Pessi@nokia.com, Jari.Urpalainen@nokia.com, simple@ietf.org, RjS@xten.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable How does this proposal sound (for the filter drafts): In the format document, the following text appears: The XML document = MUST be well-formed and MUST be valid according to schemas, including = extensions schemas, available to the validater and applicable to the XML = document. In the functionality draft: The creator MUST ensure that the XML = document is well-formed and valid. The creator MUST NOT insert any = extension elements or attributes into the XML document unless it has = access to the extension schema and can validate the XML document. The = XML document consumer MUST validate the XML document according the = schemas, including extension schemas, it has access to that are = applicable to this XML document. For pidf, the second part might be slightly different since the creator = of the document can be the compositor and the compositor can create a = presence XML document by aggregating tuples that contain extensions that = the compositor is unaware of. Perhaps something can go in the Date Model = draft discussing this. Regards, Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Pekka Pessi > Sent: 20.September.2004 14:36 > To: Jonathan Rosenberg > Cc: Pessi Pekka (Nokia-NRC/Helsinki); Urpalainen Jari > (Nokia-NRC/Helsinki); simple@ietf.org; Robert Sparks > Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE > documents >=20 >=20 > Jonathan Rosenberg writes: > >I'm saying that a document of type application/pidf+xml=20 > could be valid > >against the PIDF schema, but it contains extensions (which=20 > are allowed in > >the pidf schema), and those extensions make use of elements=20 > defined in > >another schema. However, those elements are not valid=20 > according to that > >other schema. >=20 > >In this case, do we consider this document "valid"? >=20 > Term valid has at least three different senses with the XML: >=20 > 1)=20 >=20 > W3C defines that an XML document is valid when it has a DTD and > the document complies with the constraints set forth in DTD. >=20 > That is not what we want. No for presence, no "MUST be > valid", please. >=20 > (When RFC 3863 says that the application/pidf+xml document MUST > be well-formed and SHOULD be valid, I guess it just says that > extensions are allowed, even if they are not shown in the DTD.) >=20 > 2)=20 >=20 > XML schema specification uses a bit different terminology. Schemas > don't specify documents, but trees (item and all its descendants).=20 > You can assess validity of a particular tree, for instance, all > the XML stuff within element. The validator can also > skip certain elements (like the wildcard elements used for > extending pidf). So, validator can return different results: tree > and items within it are fully validated, partially validated, or > not validated at all. Also each, item within the tree are valid or > invalid or their validity is not known. =20 >=20 > I'd say that the XML document is schema-valid if its root element > is fully validated and it and all its descendants are valid. This > is not the official definition, however. >=20 > This is unfeasible for the intermediate nodes (or processes), too.=20 > Unless the node knows the schema (and semantics) of all the > extensions, it cannot assess the validity of composed or filtered > documents. I think filtering and composing is precisely the things > that we want to do in the server nodes. >=20 > I can also imagine some applications that would just use existing > presence service, just add their non-standard application-specific > status in the published presence document. Now imagine two of > those applications running on the same node. >=20 > 3) >=20 > Beside validity assessment, XML schema specification has the > concept of "local schema-validity", too: >=20 > >=20 > I must admit that I don't fully understand what this > means, but I have a good hunch that it is what most of us > want. ;) >=20 > A element or attribute is valid if it satisfies the constraints > set by the XML schema. So, element is valid, if it > contains entity attribute, zero or more elements, then > zero or more elements and after then something wildcarded > stuff (I guess that is anything else but pidf-namespace stuff). I > don't understand how the datatype checking of evil types like > xs:ID or xs:IDREF is done when the "local schema-validity" is > determined. I *guess* that ID/IDREF attribute in tuple is valid if > its value is syntactically correct. Like id=3D"_123" is valid but, > id=3D"123" is not. No check for all id's within a document/item and > all of its descendats is required. >=20 > So, if we have a application/pidf+xml document, we can simply say > that it MUST conform to its schema and other requirements set > forth in RFC 3863. If we want to be more verbose, we could say > that the root node in the document MUST be partially or fully > validated and none of the validated nodes MUST NOT be invalid. Or > we could invent our own term and say that documents MUST be > locally-schema-valid with the schema XXX. >=20 > --Pekka >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 23 04:22:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21551; Thu, 23 Sep 2004 04:22:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAOyS-0002Zi-Cj; Thu, 23 Sep 2004 04:29:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAOlA-0003TN-KZ; Thu, 23 Sep 2004 04:15:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAOji-0003G4-Ln for simple@megatron.ietf.org; Thu, 23 Sep 2004 04:13:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21078 for ; Thu, 23 Sep 2004 04:13:52 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAOqS-0002QK-PS for simple@ietf.org; Thu, 23 Sep 2004 04:20:53 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8N8Do104415 for ; Thu, 23 Sep 2004 11:13:51 +0300 (EET DST) X-Scanned: Thu, 23 Sep 2004 11:13:32 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i8N8DWPw023323 for ; Thu, 23 Sep 2004 11:13:32 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 004chVty; Thu, 23 Sep 2004 11:11:02 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8N8AvS14028 for ; Thu, 23 Sep 2004 11:10:57 +0300 (EET DST) Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 23 Sep 2004 11:10:21 +0300 Received: from esebe052.NOE.Nokia.com ([172.21.138.217]) by esebe021.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 23 Sep 2004 11:10:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Sep 2004 11:10:21 +0300 Message-ID: Thread-Topic: [Simple] MSRP URLs Thread-Index: AcSfxakU0zg0aVx0R6iXWEZaAG0+dgAFTClQ To: X-OriginalArrivalTime: 23 Sep 2004 08:10:21.0639 (UTC) FILETIME=[C57D5570:01C4A144] X-Spam-Score: 0.3 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Subject: [Simple] Presence Data Model: Identifying services X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Hi all, I have a comment on Presence Data Model draft about the = identification/characterization of services. (I know this has been = discussed for a while already, but I still think the current way is = somewhat unadequate.) The current Data Model draft says: In this model, services are not explicitly enumerated. That is, there is no "service" attribute with values of "ptt" or "telephony". Rather, the service is identified in one of two ways. In many cases, the URI scheme is a clear indicator of service. An "sms" URI clearly indicates SMS, and a "tel" URI clearly indicates telephony. For some URIs, there may be many services available, for example, SIP. For those services, each service has a set of characteristics, each of which has a well-defined meaning, such that a system can unequivocally determine whether or not the service has that characteristic. This is discussed in more detail in [5].=20 I agree that the contact URI scheme is the most important piece of = information to distinguish what is the "service". (There are some gaps = here too, since e.g. the URI schemes for SMS or MMS do not even exist, = and there may be other non-IETF protocols that face the same problem.) = However, I'm not convinced that listing the signaling/media = characteristics of the end-point or service really gives enough = information to the watcher to really determine if it can communicate = with the advertised service/application.=20 The refenced draft [5] has a following example: 5.6 Walkie-talkie The walkie-talkie service allows real-time voice communication between participants. Only one participant can speak at a time; that is, communication is half-duplex. Typically, participants press a button to indicate that they are ready to speak, although other mechanism (e.g. voice activation) are occasionally used. Support for the Walkie-Talkie service can be deduced by observing the presence of a contact URI with a scheme of "sip:", associated with the following minimal set of capabilities: half INVITE,ACK,BYE,CANCEL Presumably this is the same as the service sometimes called Push-to-Talk = (PTT, PoC). The concrete problem is that there are several = _non-interworking_ variants of this service, that still all would match = the characteristics listed above, as the _SIP_ part might still be = standard, at least for some methods etc. But still the communication = would fail even if the tuple looks OK. (Also if I saw the = characteristics above, I could as well determine that they describe = normal VoIP application running in (very) some old PC with half-duplex = audio drivers, so I claim the service description is hard to make = unambiguous in the first place.) =20 =20 I think the main point of a service tuple is to give the watcher enough = information to know whether he can really communicate & interoperate = with the advertised service. Given that many services taht are using SIP = also have propritary or non-SIP features, I don't think the current = approach is enough.=20 Of course each of these proprietary services are allowed to define = additional status or tuple-level extensions to PIDF. However, I would = like to have some kind of "service identifier" as part of the basic = framework so that this could be done in a consistent manner. I think it = would help especially in making of authorization and composition rules = more simple. The current "class" attribute is way too loosely defined. So the concrete proposal is to include in RPID a "service id" element = that would have a vendor-specific namespace, similar to e.g. = vendor-specific XCAP AUIDs. So for instance the SIP-based PTT app from = vendor xyz.com would have, e.g.=20 com.xyz.ptt while the PTT app compliant with OMA would have, e.g. com.openmobilealliance.ptt in _addition_ to describing sip:, half-duplex audio, and the supported = methods. Now: 1.) Watcher having one of those apps could see right away whether it is = possible to communicate 2.) Composer getting PUBLISHes from 2 sources could immediately know = that they are from a similar app 3.) The app could set its authorization rules using the unique id. The main downside I can see in this approach that if there are two = different proprietary apps that indeed could communicate at least = partially, the watcher might make a conclusion that communication is not = possible baed on different service-id. However, in this case the watcher = still would have the characteristics visible and could determine that = some interworking could be achieved. For this kind of reasons there = should be careful text about when to use service-id in the first place, = and what can be determined from it. Does someone think that this is an absolutely bad idea? If so, how would = you envision solving the issues discussed above? Regards, Markus=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 23 07:49:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03603; Thu, 23 Sep 2004 07:49:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CASDV-0005wo-CD; Thu, 23 Sep 2004 07:56:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAS3J-0005IS-BL; Thu, 23 Sep 2004 07:46:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAS0r-0004oD-HP for simple@megatron.ietf.org; Thu, 23 Sep 2004 07:43:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03210 for ; Thu, 23 Sep 2004 07:43:48 -0400 (EDT) Received: from mailhost.atea.be ([194.78.143.125] helo=hermes.atea.be) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAS6d-0005oe-Po for simple@ietf.org; Thu, 23 Sep 2004 07:50:50 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by hermes.atea.be (8.11.1/8.11.1) with ESMTP id i8NBebE28377 for ; Thu, 23 Sep 2004 13:40:40 +0200 (MDT) Received: from bruc100e.sbs.be (bruc100e.sbs.be [193.210.175.22]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i8NBfexK003733 for ; Thu, 23 Sep 2004 13:41:40 +0200 Received: by bruc100e.sbs.be with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Sep 2004 13:40:52 +0200 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F19569219B@hrtades7.atea.be> From: Goeman Stefan To: "'simple@ietf.org'" Subject: RE: [Simple] Presence Data Model: Identifying services Date: Thu, 23 Sep 2004 13:41:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Hello, Comments inline P.S.: In general, I find the Presence Data model draft a good document. This is how things should have started in the first place. Greetings, Stefan. > -----Original Message----- > From: simple-bounces@ietf.org > [mailto:simple-bounces@ietf.org] On Behalf Of Markus.Isomaki@nokia.com > Sent: donderdag 23 september 2004 10:10 > To: simple@ietf.org > Subject: [Simple] Presence Data Model: Identifying services > > > Hi all, > > I have a comment on Presence Data Model draft about the > identification/characterization of services. (I know this has > been discussed for a while already, but I still think the > current way is somewhat unadequate.) > > The current Data Model draft says: > > In this model, services are not explicitly enumerated. That is, > there is no "service" attribute with values of "ptt" or > "telephony". > Rather, the service is identified in one of two ways. In > many cases, > the URI scheme is a clear indicator of service. An "sms" > URI clearly > indicates SMS, and a "tel" URI clearly indicates > telephony. For some > URIs, there may be many services available, for example, SIP. For > those services, each service has a set of characteristics, each of > which has a well-defined meaning, such that a system can > unequivocally determine whether or not the service has that > characteristic. This is discussed in more detail in [5]. > > I agree that the contact URI scheme is the most important > piece of information to distinguish what is the "service". > (There are some gaps here too, since e.g. the URI schemes for > SMS or MMS do not even exist, and there may be other non-IETF > protocols that face the same problem.) However, I'm not > convinced that listing the signaling/media characteristics of > the end-point or service really gives enough information to > the watcher to really determine if it can communicate with > the advertised service/application. > > The refenced draft [5] has a following example: > > 5.6 Walkie-talkie > > The walkie-talkie service allows real-time voice communication > between participants. Only one participant can speak at a > time; that > is, communication is half-duplex. Typically, participants press a > button to indicate that they are ready to speak, although other > mechanism (e.g. voice activation) are occasionally used. > > Support for the Walkie-Talkie service can be deduced by > observing the > presence of a contact URI with a scheme of "sip:", associated with > the following minimal set of capabilities: > half INVITE,ACK,BYE,CANCEL > > Presumably this is the same as the service sometimes called > Push-to-Talk (PTT, PoC). The concrete problem is that there > are several _non-interworking_ variants of this service, that > still all would match the characteristics listed above, as > the _SIP_ part might still be standard, at least for some > methods etc. But still the communication would fail even if > the tuple looks OK. I don't think I understand you here. I would expect that if both end-point SIP US support exactly the same methods, the SIP UA should also be able to handle those SIP method. Or, to phase it in another way, both end-point should be able to communicate with each other only based on using these capabilities. > (Also if I saw the characteristics above, > I could as well determine that they describe normal VoIP > application running in (very) some old PC with half-duplex > audio drivers, so I claim the service description is hard to > make unambiguous in the first place.) > I also have the impression that it will be difficult to determine the services merely based on the SIP methods (and ...) supported by the SIP UA. It possibly might mean that the SIP-based ptt-service on my mobile phone might be mapped onto some communication service on your PC. Then, I wonder who will be responsible for such kind of mapping? Only the end terminals, or is support from the network, presence server, necessary? And, how will one service in one domain be mapped into a service in another domain? I believe there are some open issues here. > I think the main point of a service tuple is to give the > watcher enough information to know whether he can really > communicate & interoperate with the advertised service. Given > that many services taht are using SIP also have propritary or > non-SIP features, I don't think the current approach is enough. > Do you have an example of a service that uses SIP and also has non SIP-features? If your service also uses non-SIP features, you can not determine the type of service by only looking at the SIP capabilities supported by the SIP UA. Some indication of that non-SIP feature should also be present in the presence document. > Of course each of these proprietary services are allowed to > define additional status or tuple-level extensions to PIDF. Yes, you can always extend the PIDF. My comment here is that this might lead to an "explosion" of applications or services. It will certainly not help interoperability. > However, I would like to have some kind of "service > identifier" as part of the basic framework so that this could > be done in a consistent manner. I think it would help > especially in making of authorization and composition rules > more simple. The current "class" attribute is way too loosely defined. > > So the concrete proposal is to include in RPID a "service id" > element that would have a vendor-specific namespace, similar > to e.g. vendor-specific XCAP AUIDs. So for instance the > SIP-based PTT app from vendor xyz.com would have, e.g. > > com.xyz.ptt > > while the PTT app compliant with OMA would have, e.g. > > com.openmobilealliance.ptt > In general, I could agree with that approach. However, I don't see a reason why the vendor specific SIP-based PTT should be different from the OMA based PTT. Simply define one PTT, based on the SIP UA capabilities. > in _addition_ to describing sip:, half-duplex audio, and the > supported methods. Now: > 1.) Watcher having one of those apps could see right away > whether it is possible to communicate > 2.) Composer getting PUBLISHes from 2 sources could > immediately know that they are from a similar app > 3.) The app could set its authorization rules using the unique id. > > The main downside I can see in this approach that if there > are two different proprietary apps that indeed could > communicate at least partially, the watcher might make a > conclusion that communication is not possible baed on > different service-id. However, in this case the watcher still > would have the characteristics visible and could determine > that some interworking could be achieved. Personally, I don't think it is a good idea that an end-user should make such decission. If I get a presence document that indicates that another person is able to receive some type of communication, I expect that that type of communication would actually work when I use it. >For this kind of > reasons there should be careful text about when to use > service-id in the first place, and what can be determined from it. > > Does someone think that this is an absolutely bad idea? If > so, how would you envision solving the issues discussed above? > I think more care should be taken in mapping SIP UA capabilities into actual services. That is not so clear to me! > Regards, > Markus > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 23 08:45:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08566; Thu, 23 Sep 2004 08:45:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAT4v-000757-2f; Thu, 23 Sep 2004 08:52:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CASuh-0002VF-M8; Thu, 23 Sep 2004 08:41:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CASoM-00020p-T4 for simple@megatron.ietf.org; Thu, 23 Sep 2004 08:34:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07111 for ; Thu, 23 Sep 2004 08:34:57 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CASv8-0006t0-So for simple@ietf.org; Thu, 23 Sep 2004 08:41:59 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8NCYtg07357; Thu, 23 Sep 2004 15:34:55 +0300 (EET DST) X-Scanned: Thu, 23 Sep 2004 15:34:39 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i8NCYdrr027775; Thu, 23 Sep 2004 15:34:39 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00ymDWUn; Thu, 23 Sep 2004 15:34:22 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8NCYKY14969; Thu, 23 Sep 2004 15:34:20 +0300 (EET DST) Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 23 Sep 2004 15:34:17 +0300 Received: from esebe052.NOE.Nokia.com ([172.21.138.217]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 23 Sep 2004 15:34:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Presence Data Model: Identifying services Date: Thu, 23 Sep 2004 15:34:08 +0300 Message-ID: Thread-Topic: [Simple] Presence Data Model: Identifying services Thread-Index: AcShZM7RroMlKF9vQ1WmntzKQG6NEgAAODlA To: , X-OriginalArrivalTime: 23 Sep 2004 12:34:15.0476 (UTC) FILETIME=[A3311F40:01C4A169] X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Content-Transfer-Encoding: quoted-printable Hi Stefan, Comments back to you inline.=20 (Yes, I absolutely agree with you on the usefulness of the Presence Data = Model draft and that it should have been the starting point, at least = right after PIDF.) > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Goeman Stefan > Sent: 23 September, 2004 14:42 > To: 'simple@ietf.org' > Subject: RE: [Simple] Presence Data Model: Identifying services >=20 >=20 > Hello, >=20 > Comments inline >=20 > P.S.: In general, I find the Presence Data model draft a good=20 > document. This > is how things should have started in the first place. >=20 > Greetings, > Stefan. >=20 > > -----Original Message----- > > From: simple-bounces@ietf.org=20 > > [mailto:simple-bounces@ietf.org] On Behalf Of=20 > Markus.Isomaki@nokia.com > > Sent: donderdag 23 september 2004 10:10 > > To: simple@ietf.org > > Subject: [Simple] Presence Data Model: Identifying services > >=20 > >=20 > > Hi all, > >=20 > > I have a comment on Presence Data Model draft about the=20 > > identification/characterization of services. (I know this has=20 > > been discussed for a while already, but I still think the=20 > > current way is somewhat unadequate.) > >=20 > > The current Data Model draft says: > >=20 > > In this model, services are not explicitly enumerated. That is, > > there is no "service" attribute with values of "ptt" or=20 > > "telephony". > > Rather, the service is identified in one of two ways. In=20 > > many cases, > > the URI scheme is a clear indicator of service. An "sms"=20 > > URI clearly > > indicates SMS, and a "tel" URI clearly indicates=20 > > telephony. For some > > URIs, there may be many services available, for example,=20 > SIP. For > > those services, each service has a set of=20 > characteristics, each of > > which has a well-defined meaning, such that a system can > > unequivocally determine whether or not the service has that > > characteristic. This is discussed in more detail in [5].=20 > >=20 > > I agree that the contact URI scheme is the most important=20 > > piece of information to distinguish what is the "service".=20 > > (There are some gaps here too, since e.g. the URI schemes for=20 > > SMS or MMS do not even exist, and there may be other non-IETF=20 > > protocols that face the same problem.) However, I'm not=20 > > convinced that listing the signaling/media characteristics of=20 > > the end-point or service really gives enough information to=20 > > the watcher to really determine if it can communicate with=20 > > the advertised service/application.=20 > >=20 > > The refenced draft [5] has a following example: > >=20 > > 5.6 Walkie-talkie > >=20 > > The walkie-talkie service allows real-time voice communication > > between participants. Only one participant can speak at a=20 > > time; that > > is, communication is half-duplex. Typically,=20 > participants press a > > button to indicate that they are ready to speak, although other > > mechanism (e.g. voice activation) are occasionally used. > >=20 > > Support for the Walkie-Talkie service can be deduced by=20 > > observing the > > presence of a contact URI with a scheme of "sip:",=20 > associated with > > the following minimal set of capabilities: > > half INVITE,ACK,BYE,CANCEL > >=20 > > Presumably this is the same as the service sometimes called=20 > > Push-to-Talk (PTT, PoC). The concrete problem is that there=20 > > are several _non-interworking_ variants of this service, that=20 > > still all would match the characteristics listed above, as=20 > > the _SIP_ part might still be standard, at least for some=20 > > methods etc. But still the communication would fail even if=20 > > the tuple looks OK. > I don't think I understand you here. I would expect that if=20 > both end-point > SIP US support exactly the same methods, the SIP UA should=20 > also be able to > handle those SIP method. Or, to phase it in another way, both=20 > end-point > should be able to communicate with each other only based on=20 > using these > capabilities. > To some extent that might be possible, but there might be differences = e.g. in floor control etc., which make the service still practically = unusable, which means that the presence document shouldn't give the = impression that the communication will work. Obviously it is possible to = list all those additional characteristics as well (and this might be a = good idea too), but for instance if presence of a network game is = published, it is easier to _explicitely_ tell what the game is by = providing some sort of unique id which would be only meaningful to those = similar game clients. =20 =20 > > (Also if I saw the characteristics above,=20 > > I could as well determine that they describe normal VoIP=20 > > application running in (very) some old PC with half-duplex=20 > > audio drivers, so I claim the service description is hard to=20 > > make unambiguous in the first place.) =20 > > > I also have the impression that it will be difficult to determine the > services merely based on the SIP methods (and ...) supported=20 > by the SIP UA. > It possibly might mean that the SIP-based ptt-service on my=20 > mobile phone > might be mapped onto some communication service on your PC.=20 > Then, I wonder > who will be responsible for such kind of mapping? Only the=20 > end terminals, or > is support from the network, presence server, necessary? And,=20 > how will one > service in one domain be mapped into a service in another=20 > domain? I believe > there are some open issues here.=20 > I think that it is fully OK to describe some rather simple things using = characteristics, but in many cases applications are more complex. =20 > > I think the main point of a service tuple is to give the=20 > > watcher enough information to know whether he can really=20 > > communicate & interoperate with the advertised service. Given=20 > > that many services taht are using SIP also have propritary or=20 > > non-SIP features, I don't think the current approach is enough.=20 > >=20 > Do you have an example of a service that uses SIP and also has non > SIP-features? If your service also uses non-SIP features, you can not > determine the type of service by only looking at the SIP capabilities > supported by the SIP UA. Some indication of that non-SIP=20 > feature should also > be present in the presence document.=20 >=20 True, and since some of those non-SIP features might not be based on = (IETF) standards, it might be good to have the possibility for the = developers of such applications to have a short cut of saying what the = app really is, rather than having to list characteristics. In the end, = some applications are really not even meant to work with any other than = the exactly same application, for instance some networking games.=20 > > Of course each of these proprietary services are allowed to=20 > > define additional status or tuple-level extensions to PIDF. > Yes, you can always extend the PIDF. My comment here is that=20 > this might lead > to an "explosion" of applications or services. It will=20 > certainly not help > interoperability. > =20 And who would standardize such characteristic definitions. It has = already taken a couple of years to standardize even "prescaps", which is = just a starting point.=20 > > However, I would like to have some kind of "service=20 > > identifier" as part of the basic framework so that this could=20 > > be done in a consistent manner. I think it would help=20 > > especially in making of authorization and composition rules=20 > > more simple. The current "class" attribute is way too=20 > loosely defined. > >=20 > > So the concrete proposal is to include in RPID a "service id"=20 > > element that would have a vendor-specific namespace, similar=20 > > to e.g. vendor-specific XCAP AUIDs. So for instance the=20 > > SIP-based PTT app from vendor xyz.com would have, e.g.=20 > >=20 > > com.xyz.ptt > >=20 > > while the PTT app compliant with OMA would have, e.g. > >=20 > > com.openmobilealliance.ptt > >=20 > In general, I could agree with that approach. However, I=20 > don't see a reason > why the vendor specific SIP-based PTT should be different=20 > from the OMA based > PTT. Simply define one PTT, based on the SIP UA capabilities. >=20 Well, for instance Nokia has a prorietary PTT application, which uses = SIP INVITE etc., so users are essentially addressed with sip: URI. = However, it has some floor control, media etc. features which make it = basically non-interoperable with clients that are not specifically = following that proprietary spec.=20 OMA PTT is closer to standard IETF SIP. Unless there is some conversion, = it does not work with Nokia PTT directly. There should be some way for = distinguishing these two in a presence document, so that there won't be = confusion. I think the current idea is to do some kind of proprietary = PIDF extensions, but in my opinion a standard XML element in RPID to = tell this kind of information would be better, also for the purposes of = authorization rule making. > > in _addition_ to describing sip:, half-duplex audio, and the=20 > > supported methods. Now: > > 1.) Watcher having one of those apps could see right away=20 > > whether it is possible to communicate > > 2.) Composer getting PUBLISHes from 2 sources could=20 > > immediately know that they are from a similar app > > 3.) The app could set its authorization rules using the unique id. > >=20 > > The main downside I can see in this approach that if there=20 > > are two different proprietary apps that indeed could=20 > > communicate at least partially, the watcher might make a=20 > > conclusion that communication is not possible baed on=20 > > different service-id. However, in this case the watcher still=20 > > would have the characteristics visible and could determine=20 > > that some interworking could be achieved.=20 > Personally, I don't think it is a good idea that an end-user=20 > should make > such decission. If I get a presence document that indicates=20 > that another > person is able to receive some type of communication, I=20 > expect that that > type of communication would actually work when I use it. >=20 Exactly right. If you are an application who does not necessarily aim = for interoperability, but still uses sip:, INVITE etc., you should be = able to explicitely say so. > >For this kind of=20 > > reasons there should be careful text about when to use=20 > > service-id in the first place, and what can be determined from it. > >=20 > > Does someone think that this is an absolutely bad idea? If=20 > > so, how would you envision solving the issues discussed above? > >=20 > I think more care should be taken in mapping SIP UA=20 > capabilities into actual > services. That is not so clear to me! > The idea is nice, but I don't see a problem in _addition_ defining the = application with something like "com.openmobilealliance.ptt" or = "com.nokia.ptt", if that kind of profile would have more meaning than = the list of characteristics. =20 >=20 > > Regards, > > Markus=20 > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 23 08:59:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09765; Thu, 23 Sep 2004 08:59:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CATJ9-0007MW-VE; Thu, 23 Sep 2004 09:06:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAT93-0004TC-VV; Thu, 23 Sep 2004 08:56:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAT8N-0004IE-TI for simple@megatron.ietf.org; Thu, 23 Sep 2004 08:55:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09282 for ; Thu, 23 Sep 2004 08:55:38 -0400 (EDT) Received: from cmailm2.svr.pol.co.uk ([195.92.193.210]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CATFA-0007H8-Lv for simple@ietf.org; Thu, 23 Sep 2004 09:02:41 -0400 Received: from user-5212.l3.c4.dsl.pol.co.uk ([81.79.212.92] helo=RW) by cmailm2.svr.pol.co.uk with smtp (Exim 4.14) id 1CAT8J-0001nF-Ed; Thu, 23 Sep 2004 13:55:35 +0100 Message-ID: <000d01c4a16c$9e9129f0$c700a8c0@RW> From: "Pete Cordell" To: References: <5816828233DEFA41807A6CFDFDF2343C08B62E@esebe056.ntc.nokia.com> Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE documents Date: Thu, 23 Sep 2004 13:55:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: 7bit Hi Hisham, For my money, your statements are roughly right. The only concern I have is the bit where it says: "...consumer MUST validate...". It's probably not the intent, but there's a potential implication that the IETF is saying that consumers must run a separate validation exercise on the received data (rather than say implicitly validating while the application interprets the data, in which case they may only end up validating the parts of the data they are interested in). It sounds like the IETF is saying how people should build their devices which traditionally they haven't done. It's probably not a big issue, but a possible re-wording is:- "The XML document received by a consumer MUST be valid according the schemas, including extension schemas, the consumer has access to that are applicable to this XML document. The consumer MAY validate the received XML document against such schemas, and MAY reject the XML document if such validation is not successful." I'll leave it to you. Pete. -- ============================================= Pete Cordell Tech-Know-Ware pete(at)tech-know-ware.com http://www.tech-know-ware.com http://www.xml2cpp.com - Now Available +44 1473 635863 ============================================= ----- Original Message ----- From: To: ; Cc: ; ; ; Sent: Wednesday, September 22, 2004 9:54 AM Subject: RE: [Simple] Strength of XML validity requirements in SIMPLE documents How does this proposal sound (for the filter drafts): In the format document, the following text appears: The XML document MUST be well-formed and MUST be valid according to schemas, including extensions schemas, available to the validater and applicable to the XML document. In the functionality draft: The creator MUST ensure that the XML document is well-formed and valid. The creator MUST NOT insert any extension elements or attributes into the XML document unless it has access to the extension schema and can validate the XML document. The XML document consumer MUST validate the XML document according the schemas, including extension schemas, it has access to that are applicable to this XML document. For pidf, the second part might be slightly different since the creator of the document can be the compositor and the compositor can create a presence XML document by aggregating tuples that contain extensions that the compositor is unaware of. Perhaps something can go in the Date Model draft discussing this. Regards, Hisham > -----Original Message----- > From: simple-bounces@ietf.org > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Pekka Pessi > Sent: 20.September.2004 14:36 > To: Jonathan Rosenberg > Cc: Pessi Pekka (Nokia-NRC/Helsinki); Urpalainen Jari > (Nokia-NRC/Helsinki); simple@ietf.org; Robert Sparks > Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE > documents > > > Jonathan Rosenberg writes: > >I'm saying that a document of type application/pidf+xml > could be valid > >against the PIDF schema, but it contains extensions (which > are allowed in > >the pidf schema), and those extensions make use of elements > defined in > >another schema. However, those elements are not valid > according to that > >other schema. > > >In this case, do we consider this document "valid"? > > Term valid has at least three different senses with the XML: > > 1) > > W3C defines that an XML document is valid when it has a DTD and > the document complies with the constraints set forth in DTD. > > That is not what we want. No for presence, no "MUST be > valid", please. > > (When RFC 3863 says that the application/pidf+xml document MUST > be well-formed and SHOULD be valid, I guess it just says that > extensions are allowed, even if they are not shown in the DTD.) > > 2) > > XML schema specification uses a bit different terminology. Schemas > don't specify documents, but trees (item and all its descendants). > You can assess validity of a particular tree, for instance, all > the XML stuff within element. The validator can also > skip certain elements (like the wildcard elements used for > extending pidf). So, validator can return different results: tree > and items within it are fully validated, partially validated, or > not validated at all. Also each, item within the tree are valid or > invalid or their validity is not known. > > I'd say that the XML document is schema-valid if its root element > is fully validated and it and all its descendants are valid. This > is not the official definition, however. > > This is unfeasible for the intermediate nodes (or processes), too. > Unless the node knows the schema (and semantics) of all the > extensions, it cannot assess the validity of composed or filtered > documents. I think filtering and composing is precisely the things > that we want to do in the server nodes. > > I can also imagine some applications that would just use existing > presence service, just add their non-standard application-specific > status in the published presence document. Now imagine two of > those applications running on the same node. > > 3) > > Beside validity assessment, XML schema specification has the > concept of "local schema-validity", too: > > > > I must admit that I don't fully understand what this > means, but I have a good hunch that it is what most of us > want. ;) > > A element or attribute is valid if it satisfies the constraints > set by the XML schema. So, element is valid, if it > contains entity attribute, zero or more elements, then > zero or more elements and after then something wildcarded > stuff (I guess that is anything else but pidf-namespace stuff). I > don't understand how the datatype checking of evil types like > xs:ID or xs:IDREF is done when the "local schema-validity" is > determined. I *guess* that ID/IDREF attribute in tuple is valid if > its value is syntactically correct. Like id="_123" is valid but, > id="123" is not. No check for all id's within a document/item and > all of its descendats is required. > > So, if we have a application/pidf+xml document, we can simply say > that it MUST conform to its schema and other requirements set > forth in RFC 3863. If we want to be more verbose, we could say > that the root node in the document MUST be partially or fully > validated and none of the validated nodes MUST NOT be invalid. Or > we could invent our own term and say that documents MUST be > locally-schema-valid with the schema XXX. > > --Pekka > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 23 12:16:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26600; Thu, 23 Sep 2004 12:16:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAWNC-00037S-MD; Thu, 23 Sep 2004 12:23:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAW5T-0006lJ-HA; Thu, 23 Sep 2004 12:04:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAVog-0003Ak-90 for simple@megatron.ietf.org; Thu, 23 Sep 2004 11:47:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24527 for ; Thu, 23 Sep 2004 11:47:27 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAVvT-0002U5-VQ for simple@ietf.org; Thu, 23 Sep 2004 11:54:33 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 23 Sep 2004 08:47:04 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8NFkrwp015588; Thu, 23 Sep 2004 08:46:54 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALT95506; Thu, 23 Sep 2004 11:46:54 -0400 (EDT) Message-ID: <4152EFED.9030206@cisco.com> Date: Thu, 23 Sep 2004 11:46:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: [Simple] Presence Data Model: Identifying services References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 Content-Transfer-Encoding: 7bit I have comments both to Markus' original posting and to the ensuing discussion. So I will just insert inline in the latest response I have. Paul Markus.Isomaki@nokia.com wrote: > Hi Stefan, > > Comments back to you inline. > > (Yes, I absolutely agree with you on the usefulness of the Presence Data Model draft and that it should have been the starting point, at least right after PIDF.) > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org]On Behalf >>Of ext Goeman Stefan >>Sent: 23 September, 2004 14:42 >>To: 'simple@ietf.org' >>Subject: RE: [Simple] Presence Data Model: Identifying services >> >> >>Hello, >> >>Comments inline >> >>P.S.: In general, I find the Presence Data model draft a good >>document. This >>is how things should have started in the first place. >> >>Greetings, >>Stefan. >> >> >>>-----Original Message----- >>>From: simple-bounces@ietf.org >>>[mailto:simple-bounces@ietf.org] On Behalf Of >> >>Markus.Isomaki@nokia.com >> >>>Sent: donderdag 23 september 2004 10:10 >>>To: simple@ietf.org >>>Subject: [Simple] Presence Data Model: Identifying services >>> >>> >>>Hi all, >>> >>>I have a comment on Presence Data Model draft about the >>>identification/characterization of services. (I know this has >>>been discussed for a while already, but I still think the >>>current way is somewhat unadequate.) >>> >>>The current Data Model draft says: >>> >>> In this model, services are not explicitly enumerated. That is, >>> there is no "service" attribute with values of "ptt" or >>>"telephony". >>> Rather, the service is identified in one of two ways. In >>>many cases, >>> the URI scheme is a clear indicator of service. An "sms" >>>URI clearly >>> indicates SMS, and a "tel" URI clearly indicates >>>telephony. I don't find the scheme as clearcut as that. I don't think one should assume "tel" indicates telephony. It perhaps does imply reachability via various telephony protocols for purpose of voice communications, but is not exclusive to that. If the tel: URI can be mapped to a sip endpoint and protocol, then non-voice, non-telephony capabilities are not excluded. For instance, it may prove convenient to publish a tel URI for a sip endpoint that is capable of both voice and IM. Then calls via the PSTN will work, calls from a sip audio phone will work, calls from another voice+im client will have access to voice and IM. >>> For some >>> URIs, there may be many services available, for example, >> >>SIP. For >> >>> those services, each service has a set of >> >>characteristics, each of >> >>> which has a well-defined meaning, such that a system can >>> unequivocally determine whether or not the service has that >>> characteristic. This is discussed in more detail in [5]. >>> >>>I agree that the contact URI scheme is the most important >>>piece of information to distinguish what is the "service". >>>(There are some gaps here too, since e.g. the URI schemes for >>>SMS or MMS do not even exist, and there may be other non-IETF >>>protocols that face the same problem.) However, I'm not >>>convinced that listing the signaling/media characteristics of >>>the end-point or service really gives enough information to >>>the watcher to really determine if it can communicate with >>>the advertised service/application. >>> >>>The refenced draft [5] has a following example: >>> >>>5.6 Walkie-talkie >>> >>> The walkie-talkie service allows real-time voice communication >>> between participants. Only one participant can speak at a >>>time; that >>> is, communication is half-duplex. Typically, >> >>participants press a >> >>> button to indicate that they are ready to speak, although other >>> mechanism (e.g. voice activation) are occasionally used. >>> >>> Support for the Walkie-Talkie service can be deduced by >>>observing the >>> presence of a contact URI with a scheme of "sip:", >> >>associated with >> >>> the following minimal set of capabilities: >>> half INVITE,ACK,BYE,CANCEL >>> >>>Presumably this is the same as the service sometimes called >>>Push-to-Talk (PTT, PoC). The concrete problem is that there >>>are several _non-interworking_ variants of this service, that >>>still all would match the characteristics listed above, as >>>the _SIP_ part might still be standard, at least for some >>>methods etc. But still the communication would fail even if >>>the tuple looks OK. >> >>I don't think I understand you here. I would expect that if >>both end-point >>SIP US support exactly the same methods, the SIP UA should >>also be able to >>handle those SIP method. Or, to phase it in another way, both >>end-point >>should be able to communicate with each other only based on >>using these >>capabilities. >> > > > To some extent that might be possible, but there might be differences e.g. in floor control etc., which make the service still practically unusable, which means that the presence document shouldn't give the impression that the communication will work. Obviously it is possible to list all those additional characteristics as well (and this might be a good idea too), but for instance if presence of a network game is published, it is easier to _explicitely_ tell what the game is by providing some sort of unique id which would be only meaningful to those similar game clients. > >>>(Also if I saw the characteristics above, >>>I could as well determine that they describe normal VoIP >>>application running in (very) some old PC with half-duplex >>>audio drivers, so I claim the service description is hard to >>>make unambiguous in the first place.) I think the goal should be that all of these are at least minimally interoperable. I ought to be able to call a PTT contact from a regular voice phone and have *something* reasonable happen. (Maybe it is just oneway voice, with the non-ptt caller never getting the floor, but that may be better than nothing. I think the real problem in this case is not with the capability approach. It is that the 'duplex' capability is underspecified. There is no explanation of how a pair of half duplex endpoints (or one half-duplex and one full-duplex endpoint) agree on who can talk. In the case of the 'voice' capability, it is understood that having both endpoints support voice isn't enough to support communication. There is an SDP negotiation of codecs, etc. that either succeeds or fails. There should be something similar for half-duplex. >>I also have the impression that it will be difficult to determine the >>services merely based on the SIP methods (and ...) supported >>by the SIP UA. >>It possibly might mean that the SIP-based ptt-service on my >>mobile phone >>might be mapped onto some communication service on your PC. >>Then, I wonder >>who will be responsible for such kind of mapping? Only the >>end terminals, or >>is support from the network, presence server, necessary? And, >>how will one >>service in one domain be mapped into a service in another >>domain? I believe >>there are some open issues here. The intent is that capabilities have common meanings in all domains, so they don't need to be mapped. I don't see why there should be any binding between services and domains. In the general case one should assume that there are devices of widely varying capabilities in every domain, and that they know best what they are capable of. So the device should be the one deciding if a contact with and advertised set of capabilties is something it wants to attempt communication with. In some environment where there is an intermediary in front of a device that understands the device and acts on its behalf, then I suppose it could make these decisions. But I would consider that the odd case. > I think that it is fully OK to describe some rather simple things using characteristics, but in many cases applications are more complex. Clearly we have chosen not to describe capabilities if full detail. (E.g. we don't publish codec support.) Because of this, there is the possibility that we make a wrong decision about ability to communicate and it doesn't get discovered until we try. This is ok when the expected probability of failure is low. (We generally expect that there will be some codec in common, or that one end or the other will be able to introduce a transcoder.) >>>I think the main point of a service tuple is to give the >>>watcher enough information to know whether he can really >>>communicate & interoperate with the advertised service. Given >>>that many services taht are using SIP also have propritary or >>>non-SIP features, I don't think the current approach is enough. In cases where the existing capabilities aren't sufficient to ensure a good probability of communication, then we should indeed consider adding additional capabilities. But I continue to object to the notion of "service" as the way to do that, because it conveys no semantics about what the capability is that it describes. >>Do you have an example of a service that uses SIP and also has non >>SIP-features? If your service also uses non-SIP features, you can not >>determine the type of service by only looking at the SIP capabilities >>supported by the SIP UA. Some indication of that non-SIP >>feature should also >>be present in the presence document. >> > > > True, and since some of those non-SIP features might not be based on (IETF) standards, it might be good to have the possibility for the developers of such applications to have a short cut of saying what the app really is, rather than having to list characteristics. In the end, some applications are really not even meant to work with any other than the exactly same application, for instance some networking games. If the intent is to define a closed world, where interoperability is not even considered a desirable feature, then I agree. I think that may indeed be the case for proprietary games. But for something like PTT, while it might be in the best interest of the maker of a particular PTT solution to keep it closed, I don't think it is in the best interest of society or the IETF that this happen. This is precisely the forum in which we try to prevent that from happening. >>>Of course each of these proprietary services are allowed to >>>define additional status or tuple-level extensions to PIDF. >> >>Yes, you can always extend the PIDF. My comment here is that >>this might lead >>to an "explosion" of applications or services. It will >>certainly not help >>interoperability. My point precisely. > And who would standardize such characteristic definitions. It has already taken a couple of years to standardize even "prescaps", which is just a starting point. > > >>>However, I would like to have some kind of "service >>>identifier" as part of the basic framework so that this could >>>be done in a consistent manner. I think it would help >>>especially in making of authorization and composition rules >>>more simple. The current "class" attribute is way too >>loosely defined. >> >>>So the concrete proposal is to include in RPID a "service id" >>>element that would have a vendor-specific namespace, similar >>>to e.g. vendor-specific XCAP AUIDs. So for instance the >>>SIP-based PTT app from vendor xyz.com would have, e.g. >>>com.xyz.ptt >>>while the PTT app compliant with OMA would have, e.g. >>>com.openmobilealliance.ptt I am not fond of this solution. Done this way, we have defined an element that has no semantics at all, only syntax. I would rather see vendor specific extensions to PIDF. At least then the people that support an extension will understand what it means. But I would rather see people come forward and do the hard work of publicly defining new capabilities so that independent implementations can use them in an interoperable way. >>In general, I could agree with that approach. However, I >>don't see a reason >>why the vendor specific SIP-based PTT should be different >>from the OMA based >>PTT. Simply define one PTT, based on the SIP UA capabilities. >> > > > Well, for instance Nokia has a prorietary PTT application, which uses SIP INVITE etc., so users are essentially addressed with sip: URI. However, it has some floor control, media etc. features which make it basically non-interoperable with clients that are not specifically following that proprietary spec. This is a problem, not a good thing. I realize it has to happen as part of the development process, but the goal should be to get out of it as fast as possible. I would hope that endpoints supporting this would be described as well as possible using existing capabilities, and that a reasonable effort be made to do something reasonable when some other sip device connects. If you really can't deal with a regular voice caller at all, then I would suggest, as a transitional step, saying that you don't support voice, and then advertising some proprietary capability as an alternative to voice. > OMA PTT is closer to standard IETF SIP. Unless there is some conversion, it does not work with Nokia PTT directly. There should be some way for distinguishing these two in a presence document, so that there won't be confusion. I think the current idea is to do some kind of proprietary PIDF extensions, but in my opinion a standard XML element in RPID to tell this kind of information would be better, also for the purposes of authorization rule making. See above for what I think you could do for now. The same issues may apply to OMA PTT, and a similar solution could be applied to it. Hopefully somebody will come up with a PTT that can be dealt with more gracefully. I think that work should be done on better defining half-duplex, so that it can be used in conjunction with voice to describe PTT. But it may just turn out to be the wrong thing. Maybe we need a "floor-control" capability. >>>in _addition_ to describing sip:, half-duplex audio, and the >>>supported methods. Now: >>>1.) Watcher having one of those apps could see right away >>>whether it is possible to communicate >>>2.) Composer getting PUBLISHes from 2 sources could >>>immediately know that they are from a similar app >>>3.) The app could set its authorization rules using the unique id. >>> >>>The main downside I can see in this approach that if there >>>are two different proprietary apps that indeed could >>>communicate at least partially, the watcher might make a >>>conclusion that communication is not possible baed on >>>different service-id. This is my concern as well. >>> However, in this case the watcher still >>>would have the characteristics visible and could determine >>>that some interworking could be achieved. >> >>Personally, I don't think it is a good idea that an end-user >>should make >>such decission. If I get a presence document that indicates >>that another >>person is able to receive some type of communication, I >>expect that that >>type of communication would actually work when I use it. With high probability. There are no guarantees with presence. For instance see my mention above of codecs. > Exactly right. If you are an application who does not necessarily aim for interoperability, but still uses sip:, INVITE etc., you should be able to explicitely say so. And you can, without a special notion of service. >>>For this kind of >>>reasons there should be careful text about when to use >>>service-id in the first place, and what can be determined from it. >>> >>>Does someone think that this is an absolutely bad idea? If >>>so, how would you envision solving the issues discussed above? I still don't buy this. >>I think more care should be taken in mapping SIP UA >>capabilities into actual >>services. That is not so clear to me! > > The idea is nice, but I don't see a problem in _addition_ defining the application with something like "com.openmobilealliance.ptt" or "com.nokia.ptt", if that kind of profile would have more meaning than the list of characteristics. I am still opposed to defining an attribute with no semantics. We have been around this so many times that I am quite certain that it will never be possible to get a useful agreement on what "service" means. If it is introduced, I expect it to have problems like those of the INFO method. (The arguments for introducing it seem similar.) Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 23 12:30:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27967; Thu, 23 Sep 2004 12:30:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAWb7-0003V6-Fx; Thu, 23 Sep 2004 12:37:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAWG6-0001DZ-5Y; Thu, 23 Sep 2004 12:15:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAW1V-0005kh-G0 for simple@megatron.ietf.org; Thu, 23 Sep 2004 12:00:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25541 for ; Thu, 23 Sep 2004 12:00:42 -0400 (EDT) Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAW8I-0002lV-AI for simple@ietf.org; Thu, 23 Sep 2004 12:07:48 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i8NG0CDD013674 for ; Thu, 23 Sep 2004 18:00:12 +0200 Received: from bruc100e.sbs.be (bruc100e.sbs.be [193.210.175.22]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i8NG0AlT004974 for ; Thu, 23 Sep 2004 18:00:11 +0200 Received: by bruc100e.sbs.be with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Sep 2004 17:59:21 +0200 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F19569219F@hrtades7.atea.be> From: Goeman Stefan To: "'simple@ietf.org'" Date: Thu, 23 Sep 2004 17:57:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.6 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Subject: [Simple] Presence Authorization Rules X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============1744138437==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1744138437== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4A186.0C1C87E4" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4A186.0C1C87E4 Content-Type: text/plain; charset="iso-8859-1" Hello All, I have been reading the draft on Presence Authorization Rules, and also the draft draft-ietf-geopriv-common-policy. I have some remarks (otherwise I would not mail of course). First of all, the draft on Presence Authorization Rules contracts the geopriv draft, at least in one place. In Section 3.2 on Actions, values are given to block, confirm, ... . If you have two rules for the same entity and you combine them according to the combining rules as explained in the geopriv draft you end up with the highest value. Yet, in this case the highest value is the least privacy preserving. This is in contradiction with the statement on page 21 of the geopriv draft: "Furthermore, permissions and the meaning of their values MUST be defined in such a way that the usage of combining rules CR1, CR2, and CR3 always preserves or increases the level of privacy protection for the PT". One can argue what is wrong here. Personally, I think the statement in the geopriv draft will not really work well (see also below). Additionally, wouldn't it also be nice if one could group people into a class of people and define a rule for that class of people. For example, you could have a class of friends, family, colleagues and define a rule each of this class. The problem know arises that one person could belong to different groups. Then again, the statement in the geopriv draft will not work well. But, the best example I could think of would be the following. Suppose you have a rule for your friends (bob@example.com belong to this group) and an separate rule for bob@example.com. Now, why would you create a separate rule for bob@example.com. I would say to grant him more privileges, not less. I believe it will be easier to provide limited privileges to groups, and more privileges to "the happy few". Certainly in this case, the geopriv statement will not work; it has the opposite effect. So, In general I would say that the combining rules should be formulated in a way that it decreases the privacy of the presentity. This comes also from the fact that it was chosen to use positive rules! The same functionality could be reached by using negative rules. Greetings, Stefan. Stefan Goeman SIEMENS ICM/ICN ICM N D SE Stefan.Goeman@siemens.com phone: +32 14 253020 mobile: Fax: +32 14 22 29 94 ------_=_NextPart_001_01C4A186.0C1C87E4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Presence Authorization Rules

Hello All,

I have been reading the draft on = Presence Authorization Rules, and also the draft = draft-ietf-geopriv-common-policy.
I have some remarks (otherwise I = would not mail of course).

First of all, the draft on Presence = Authorization Rules contracts the geopriv draft, at least in one = place.
In Section 3.2 on Actions, values are = given to block, confirm, ... . If you have two rules for the same = entity and you combine them according to the combining rules as = explained in the geopriv draft you end up with the highest value. Yet, = in this case the highest value is the least privacy preserving. This is = in contradiction with the statement on page 21 of the geopriv = draft:

"Furthermore, permissions and the = meaning of their values MUST be defined in such a way that the usage of = combining rules CR1, CR2, and CR3 always preserves or increases the = level of privacy protection for the PT".

One can argue what is wrong here. = Personally, I think the statement in the geopriv draft will not really = work well (see also below).

Additionally, wouldn't it also be nice = if one could group people into a class of people and define a rule for = that class of people. For example, you could have a class of friends, = family, colleagues and define a rule each of this class. The problem = know arises that one person could belong to different groups. Then = again, the statement in the geopriv draft will not work well. =

But, the best example I could think of = would be the following. Suppose you have a rule for your friends = (bob@example.com belong to this group) and an separate rule for = bob@example.com. Now, why would you create a separate rule for = bob@example.com. I would say to grant him more privileges, not less. I = believe it will be easier to provide limited privileges to groups, and = more privileges to "the happy few". Certainly in this case, = the geopriv statement will not work; it has the opposite = effect.

So, In general I would say that the = combining rules should be formulated in a way that it decreases the = privacy of the presentity. This comes also from the fact that it was = chosen to use positive rules! The same functionality could be reached = by using negative rules.


Greetings,
Stefan.

Stefan = Goeman
SIEMENS ICM/ICN
ICM N D = SE
Stefan.Goeman@siemens.com
phone:=A0=A0 +32 14 253020
mobile:=A0
Fax:=A0=A0=A0=A0=A0=A0 +32 14 22 29 94=20

------_=_NextPart_001_01C4A186.0C1C87E4-- --===============1744138437== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1744138437==-- From simple-bounces@ietf.org Thu Sep 23 13:37:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03652; Thu, 23 Sep 2004 13:37:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAXdf-0005JL-V6; Thu, 23 Sep 2004 13:44:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAXMk-000164-1V; Thu, 23 Sep 2004 13:26:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAXDJ-0007bi-Jj for simple@megatron.ietf.org; Thu, 23 Sep 2004 13:17:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02368 for ; Thu, 23 Sep 2004 13:16:58 -0400 (EDT) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAXK6-0004wR-Is for simple@ietf.org; Thu, 23 Sep 2004 13:24:05 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id i8NHGv5S020951 for ; Thu, 23 Sep 2004 19:16:57 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id i8NHGvuC023325 for ; Thu, 23 Sep 2004 19:16:57 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 23 Sep 2004 19:16:57 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686783@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Goeman Stefan'" , "'simple@ietf.org'" Subject: RE: [Simple] Presence Authorization Rules Date: Thu, 23 Sep 2004 19:16:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 # hi stefan, # please see my comments inline. Hello All, I have been reading the draft on Presence Authorization Rules, and also the draft draft-ietf-geopriv-common-policy. I have some remarks (otherwise I would not mail of course). First of all, the draft on Presence Authorization Rules contracts the geopriv draft, at least in one place. In Section 3.2 on Actions, values are given to block, confirm, ... . If you have two rules for the same entity and you combine them according to the combining rules as explained in the geopriv draft you end up with the highest value. # to be more precise the combining permissions algorithms is applicable if two or more rules fire. Yet, in this case the highest value is the least privacy preserving. This is in contradiction with the statement on page 21 of the geopriv draft: "Furthermore, permissions and the meaning of their values MUST be defined in such a way that the usage of combining rules CR1, CR2, and CR3 always preserves or increases the level of privacy protection for the PT". One can argue what is wrong here. Personally, I think the statement in the geopriv draft will not really work well (see also below). # what would happen if jonathan changes the values corresponding to the listed actions from Block (0) Confirm (1) Polite-block (2) Allow (3) # to the following values: Block (3) Confirm (2) Polite-block (1) Allow (0) # now assume that one rule with allow(0) and another one with block(3) fires. the combining permissions algorithm would result in a block(3) action. # are you more happy with this result? Additionally, wouldn't it also be nice if one could group people into a class of people and define a rule for that class of people. For example, you could have a class of friends, family, colleagues and define a rule each of this class. The problem know arises that one person could belong to different groups. Then again, the statement in the geopriv draft will not work well. # grouping people together can be solved on a user interface basis. There is not necessarily a need to specify groups in the policies itself (except if you want to reduce the bandwidth consumption). ~snip~ # ciao # hannes _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Sep 23 16:34:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20874; Thu, 23 Sep 2004 16:34:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAaPQ-0001Wb-7x; Thu, 23 Sep 2004 16:41:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAaAy-0004Ko-KO; Thu, 23 Sep 2004 16:26:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAZz3-0005qe-RV for simple@megatron.ietf.org; Thu, 23 Sep 2004 16:14:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18482 for ; Thu, 23 Sep 2004 16:14:27 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAa5t-0000kn-VA for simple@ietf.org; Thu, 23 Sep 2004 16:21:34 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8NKEKg04275; Thu, 23 Sep 2004 23:14:20 +0300 (EET DST) X-Scanned: Thu, 23 Sep 2004 23:13:20 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i8NKDKbk029486; Thu, 23 Sep 2004 23:13:20 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00pTWnGw; Thu, 23 Sep 2004 23:13:19 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8NJpNY17857; Thu, 23 Sep 2004 22:51:23 +0300 (EET DST) Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 23 Sep 2004 22:51:23 +0300 Received: from esebe052.NOE.Nokia.com ([172.21.138.217]) by esebe021.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 23 Sep 2004 22:51:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Presence Data Model: Identifying services Date: Thu, 23 Sep 2004 22:51:22 +0300 Message-ID: Thread-Topic: [Simple] Presence Data Model: Identifying services Thread-Index: AcShhJwYSN3EFigSQ7SZ21rEELn05wAGsQiw To: X-OriginalArrivalTime: 23 Sep 2004 19:51:23.0073 (UTC) FILETIME=[B40ED310:01C4A1A6] X-Spam-Score: 0.3 (/) X-Scan-Signature: 19c92f723dac1bcdd68591cc46e38e95 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b6435b1bfa5977f2eb96dc7e52434b6d Content-Transfer-Encoding: quoted-printable Hi Paul, Thanks for your comments.=20 I guess what we both want to accomplish is this: Allow the watcher to better understand whether and how it is able to = communicate with a "service" or "communication mean" that is advertised = by the presentity.=20 The current approach is to list as many characteristics and parameters = of the service as possible, so that the watcher has as much information = as possible. In theory this works well, as long as there is some agreed = set of characteristics for each possible service. In practice there are = no guarantees, since some essential info, such as codec support, is = probably discovered only by trial and error. The concept still works = well as long as the probability of a "false positive" is reasonably low. One idea might be that the presentity should be able to declare some = capabilities as mandatory/essential, i.e. saying like "if you don't = support at least capabilities A and B, please don't contact me, since = there is no value in this from my point of view". An example might be = PTT, where the presentity could declare support for "voice", = "half-duplex", "INVITE, ..." and floor control "foo", and might insist = that even if the watcher supported the same except floor control "bar", = the communication should not be attempted. Obviously it would be in the = power of the clients and users to decide what to declare as essential = and whether to obey those declarations, but at least it would give a = hint whether things would work in a reasonable way or not. The ability = to declare something as mandatory/essential should apply also to = characteristics not understood by the watcher, e.g. if the watcher in = the example is a normal VoIP client able to do half-duplex but with no = understanding of any type of floor control (except maybe on layer 9 ;-), = it could still see that "some feature I don't understand seems to be = mandatory, so there is a high probability that the communication will = not work". In this way the evil proprietary client could hint "please = don't call me even though I'm addressable with SIP unless you know what = xyz and zyx are, since if you don't, the outcome may not be anything = useful". Is there any chance of adding this kind of mechanism? I guess it would = be some kind of attribute that would apply to all elements describing = service characteristics. I believe it should be part of the data model, = so that the designers of the proprietary extensions would know how to = use it.=20 The hard part I see is keeping the standardized characteristics = up-to-date and useful. For instance adding "floor control protocol" etc. Markus > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 23 September, 2004 18:47 > To: Isomaki Markus (Nokia-TP/Espoo) > Cc: Stefan.Goeman@siemens.com; simple@ietf.org > Subject: Re: [Simple] Presence Data Model: Identifying services >=20 >=20 > I have comments both to Markus' original posting and to the ensuing=20 > discussion. So I will just insert inline in the latest=20 > response I have. >=20 > Paul >=20 > Markus.Isomaki@nokia.com wrote: > > Hi Stefan, > >=20 > > Comments back to you inline.=20 > >=20 > > (Yes, I absolutely agree with you on the usefulness of the=20 > Presence Data Model draft and that it should have been the=20 > starting point, at least right after PIDF.) > >=20 > >=20 > >>-----Original Message----- > >>From: simple-bounces@ietf.org=20 > >>[mailto:simple-bounces@ietf.org]On Behalf > >>Of ext Goeman Stefan > >>Sent: 23 September, 2004 14:42 > >>To: 'simple@ietf.org' > >>Subject: RE: [Simple] Presence Data Model: Identifying services > >> > >> > >>Hello, > >> > >>Comments inline > >> > >>P.S.: In general, I find the Presence Data model draft a good=20 > >>document. This > >>is how things should have started in the first place. > >> > >>Greetings, > >>Stefan. > >> > >> > >>>-----Original Message----- > >>>From: simple-bounces@ietf.org=20 > >>>[mailto:simple-bounces@ietf.org] On Behalf Of=20 > >> > >>Markus.Isomaki@nokia.com > >> > >>>Sent: donderdag 23 september 2004 10:10 > >>>To: simple@ietf.org > >>>Subject: [Simple] Presence Data Model: Identifying services > >>> > >>> > >>>Hi all, > >>> > >>>I have a comment on Presence Data Model draft about the=20 > >>>identification/characterization of services. (I know this has=20 > >>>been discussed for a while already, but I still think the=20 > >>>current way is somewhat unadequate.) > >>> > >>>The current Data Model draft says: > >>> > >>> In this model, services are not explicitly enumerated. That is, > >>> there is no "service" attribute with values of "ptt" or=20 > >>>"telephony". > >>> Rather, the service is identified in one of two ways. In=20 > >>>many cases, > >>> the URI scheme is a clear indicator of service. An "sms"=20 > >>>URI clearly > >>> indicates SMS, and a "tel" URI clearly indicates=20 > >>>telephony.=20 >=20 > I don't find the scheme as clearcut as that. I don't think one should=20 > assume "tel" indicates telephony. It perhaps does imply=20 > reachability via=20 > various telephony protocols for purpose of voice=20 > communications, but is=20 > not exclusive to that. If the tel: URI can be mapped to a sip=20 > endpoint=20 > and protocol, then non-voice, non-telephony capabilities are=20 > not excluded. >=20 > For instance, it may prove convenient to publish a tel URI for a sip=20 > endpoint that is capable of both voice and IM. Then calls via=20 > the PSTN=20 > will work, calls from a sip audio phone will work, calls from another=20 > voice+im client will have access to voice and IM. >=20 > >>> For some > >>> URIs, there may be many services available, for example,=20 > >> > >>SIP. For > >> > >>> those services, each service has a set of=20 > >> > >>characteristics, each of > >> > >>> which has a well-defined meaning, such that a system can > >>> unequivocally determine whether or not the service has that > >>> characteristic. This is discussed in more detail in [5].=20 > >>> > >>>I agree that the contact URI scheme is the most important=20 > >>>piece of information to distinguish what is the "service".=20 > >>>(There are some gaps here too, since e.g. the URI schemes for=20 > >>>SMS or MMS do not even exist, and there may be other non-IETF=20 > >>>protocols that face the same problem.) However, I'm not=20 > >>>convinced that listing the signaling/media characteristics of=20 > >>>the end-point or service really gives enough information to=20 > >>>the watcher to really determine if it can communicate with=20 > >>>the advertised service/application.=20 > >>> > >>>The refenced draft [5] has a following example: > >>> > >>>5.6 Walkie-talkie > >>> > >>> The walkie-talkie service allows real-time voice communication > >>> between participants. Only one participant can speak at a=20 > >>>time; that > >>> is, communication is half-duplex. Typically,=20 > >> > >>participants press a > >> > >>> button to indicate that they are ready to speak, although other > >>> mechanism (e.g. voice activation) are occasionally used. > >>> > >>> Support for the Walkie-Talkie service can be deduced by=20 > >>>observing the > >>> presence of a contact URI with a scheme of "sip:",=20 > >> > >>associated with > >> > >>> the following minimal set of capabilities: > >>> half INVITE,ACK,BYE,CANCEL > >>> > >>>Presumably this is the same as the service sometimes called=20 > >>>Push-to-Talk (PTT, PoC). The concrete problem is that there=20 > >>>are several _non-interworking_ variants of this service, that=20 > >>>still all would match the characteristics listed above, as=20 > >>>the _SIP_ part might still be standard, at least for some=20 > >>>methods etc. But still the communication would fail even if=20 > >>>the tuple looks OK. > >> > >>I don't think I understand you here. I would expect that if=20 > >>both end-point > >>SIP US support exactly the same methods, the SIP UA should=20 > >>also be able to > >>handle those SIP method. Or, to phase it in another way, both=20 > >>end-point > >>should be able to communicate with each other only based on=20 > >>using these > >>capabilities. > >> > >=20 > >=20 > > To some extent that might be possible, but there might be=20 > differences e.g. in floor control etc., which make the=20 > service still practically unusable, which means that the=20 > presence document shouldn't give the impression that the=20 > communication will work. Obviously it is possible to list all=20 > those additional characteristics as well (and this might be a=20 > good idea too), but for instance if presence of a network=20 > game is published, it is easier to _explicitely_ tell what=20 > the game is by providing some sort of unique id which would=20 > be only meaningful to those similar game clients. > > > >>>(Also if I saw the characteristics above,=20 > >>>I could as well determine that they describe normal VoIP=20 > >>>application running in (very) some old PC with half-duplex=20 > >>>audio drivers, so I claim the service description is hard to=20 > >>>make unambiguous in the first place.) =20 >=20 > I think the goal should be that all of these are at least minimally=20 > interoperable. I ought to be able to call a PTT contact from=20 > a regular=20 > voice phone and have *something* reasonable happen. (Maybe it is just=20 > oneway voice, with the non-ptt caller never getting the=20 > floor, but that=20 > may be better than nothing. >=20 > I think the real problem in this case is not with the capability=20 > approach. It is that the 'duplex' capability is=20 > underspecified. There is=20 > no explanation of how a pair of half duplex endpoints (or one=20 > half-duplex and one full-duplex endpoint) agree on who can talk. >=20 > In the case of the 'voice' capability, it is understood that=20 > having both=20 > endpoints support voice isn't enough to support=20 > communication. There is=20 > an SDP negotiation of codecs, etc. that either succeeds or=20 > fails. There=20 > should be something similar for half-duplex. >=20 > >>I also have the impression that it will be difficult to=20 > determine the > >>services merely based on the SIP methods (and ...) supported=20 > >>by the SIP UA. > >>It possibly might mean that the SIP-based ptt-service on my=20 > >>mobile phone > >>might be mapped onto some communication service on your PC.=20 > >>Then, I wonder > >>who will be responsible for such kind of mapping? Only the=20 > >>end terminals, or > >>is support from the network, presence server, necessary? And,=20 > >>how will one > >>service in one domain be mapped into a service in another=20 > >>domain? I believe > >>there are some open issues here.=20 >=20 > The intent is that capabilities have common meanings in all=20 > domains, so=20 > they don't need to be mapped. I don't see why there should be any=20 > binding between services and domains. >=20 > In the general case one should assume that there are devices=20 > of widely=20 > varying capabilities in every domain, and that they know best=20 > what they=20 > are capable of. So the device should be the one deciding if a contact=20 > with and advertised set of capabilties is something it wants=20 > to attempt=20 > communication with. >=20 > In some environment where there is an intermediary in front=20 > of a device=20 > that understands the device and acts on its behalf, then I suppose it=20 > could make these decisions. But I would consider that the odd case. >=20 > > I think that it is fully OK to describe some rather simple=20 > things using characteristics, but in many cases applications=20 > are more complex. >=20 > Clearly we have chosen not to describe capabilities if full detail.=20 > (E.g. we don't publish codec support.) Because of this, there is the=20 > possibility that we make a wrong decision about ability to=20 > communicate=20 > and it doesn't get discovered until we try. >=20 > This is ok when the expected probability of failure is low. (We=20 > generally expect that there will be some codec in common, or that one=20 > end or the other will be able to introduce a transcoder.) >=20 > >>>I think the main point of a service tuple is to give the=20 > >>>watcher enough information to know whether he can really=20 > >>>communicate & interoperate with the advertised service. Given=20 > >>>that many services taht are using SIP also have propritary or=20 > >>>non-SIP features, I don't think the current approach is enough.=20 >=20 > In cases where the existing capabilities aren't sufficient to=20 > ensure a=20 > good probability of communication, then we should indeed=20 > consider adding=20 > additional capabilities. >=20 > But I continue to object to the notion of "service" as the way to do=20 > that, because it conveys no semantics about what the=20 > capability is that=20 > it describes. >=20 > >>Do you have an example of a service that uses SIP and also has non > >>SIP-features? If your service also uses non-SIP features,=20 > you can not > >>determine the type of service by only looking at the SIP=20 > capabilities > >>supported by the SIP UA. Some indication of that non-SIP=20 > >>feature should also > >>be present in the presence document.=20 > >> > >=20 > >=20 > > True, and since some of those non-SIP features might not be=20 > based on (IETF) standards, it might be good to have the=20 > possibility for the developers of such applications to have a=20 > short cut of saying what the app really is, rather than=20 > having to list characteristics. In the end, some applications=20 > are really not even meant to work with any other than the=20 > exactly same application, for instance some networking games.=20 >=20 > If the intent is to define a closed world, where=20 > interoperability is not=20 > even considered a desirable feature, then I agree. I think that may=20 > indeed be the case for proprietary games. >=20 > But for something like PTT, while it might be in the best interest of=20 > the maker of a particular PTT solution to keep it closed, I=20 > don't think=20 > it is in the best interest of society or the IETF that this=20 > happen. This=20 > is precisely the forum in which we try to prevent that from happening. >=20 > >>>Of course each of these proprietary services are allowed to=20 > >>>define additional status or tuple-level extensions to PIDF. > >> > >>Yes, you can always extend the PIDF. My comment here is that=20 > >>this might lead > >>to an "explosion" of applications or services. It will=20 > >>certainly not help > >>interoperability. >=20 > My point precisely. >=20 > > And who would standardize such characteristic definitions.=20 > It has already taken a couple of years to standardize even=20 > "prescaps", which is just a starting point.=20 > >=20 > >=20 > >>>However, I would like to have some kind of "service=20 > >>>identifier" as part of the basic framework so that this could=20 > >>>be done in a consistent manner. I think it would help=20 > >>>especially in making of authorization and composition rules=20 > >>>more simple. The current "class" attribute is way too=20 > >>loosely defined. > >> > >>>So the concrete proposal is to include in RPID a "service id"=20 > >>>element that would have a vendor-specific namespace, similar=20 > >>>to e.g. vendor-specific XCAP AUIDs. So for instance the=20 > >>>SIP-based PTT app from vendor xyz.com would have, e.g.=20 > >>>com.xyz.ptt > >>>while the PTT app compliant with OMA would have, e.g. > >>>com.openmobilealliance.ptt >=20 > I am not fond of this solution. Done this way, we have defined an=20 > element that has no semantics at all, only syntax. >=20 > I would rather see vendor specific extensions to PIDF. At=20 > least then the=20 > people that support an extension will understand what it means. >=20 > But I would rather see people come forward and do the hard work of=20 > publicly defining new capabilities so that independent=20 > implementations=20 > can use them in an interoperable way. >=20 > >>In general, I could agree with that approach. However, I=20 > >>don't see a reason > >>why the vendor specific SIP-based PTT should be different=20 > >>from the OMA based > >>PTT. Simply define one PTT, based on the SIP UA capabilities. > >> > >=20 > >=20 > > Well, for instance Nokia has a prorietary PTT application,=20 > which uses SIP INVITE etc., so users are essentially=20 > addressed with sip: URI. However, it has some floor control,=20 > media etc. features which make it basically non-interoperable=20 > with clients that are not specifically following that=20 > proprietary spec.=20 >=20 > This is a problem, not a good thing. I realize it has to=20 > happen as part=20 > of the development process, but the goal should be to get out=20 > of it as=20 > fast as possible. >=20 > I would hope that endpoints supporting this would be=20 > described as well=20 > as possible using existing capabilities, and that a=20 > reasonable effort be=20 > made to do something reasonable when some other sip device connects. >=20 > If you really can't deal with a regular voice caller at all, then I=20 > would suggest, as a transitional step, saying that you don't support=20 > voice, and then advertising some proprietary capability as an=20 > alternative to voice. >=20 > > OMA PTT is closer to standard IETF SIP. Unless there is=20 > some conversion, it does not work with Nokia PTT directly.=20 > There should be some way for distinguishing these two in a=20 > presence document, so that there won't be confusion. I think=20 > the current idea is to do some kind of proprietary PIDF=20 > extensions, but in my opinion a standard XML element in RPID=20 > to tell this kind of information would be better, also for=20 > the purposes of authorization rule making. >=20 > See above for what I think you could do for now. The same issues may=20 > apply to OMA PTT, and a similar solution could be applied to it. >=20 > Hopefully somebody will come up with a PTT that can be dealt=20 > with more=20 > gracefully. I think that work should be done on better defining=20 > half-duplex, so that it can be used in conjunction with voice to=20 > describe PTT. But it may just turn out to be the wrong thing.=20 > Maybe we=20 > need a "floor-control" capability. >=20 > >>>in _addition_ to describing sip:, half-duplex audio, and the=20 > >>>supported methods. Now: > >>>1.) Watcher having one of those apps could see right away=20 > >>>whether it is possible to communicate > >>>2.) Composer getting PUBLISHes from 2 sources could=20 > >>>immediately know that they are from a similar app > >>>3.) The app could set its authorization rules using the unique id. > >>> > >>>The main downside I can see in this approach that if there=20 > >>>are two different proprietary apps that indeed could=20 > >>>communicate at least partially, the watcher might make a=20 > >>>conclusion that communication is not possible baed on=20 > >>>different service-id. >=20 > This is my concern as well. >=20 > >>> However, in this case the watcher still > >>>would have the characteristics visible and could determine=20 > >>>that some interworking could be achieved.=20 > >> > >>Personally, I don't think it is a good idea that an end-user=20 > >>should make > >>such decission. If I get a presence document that indicates=20 > >>that another > >>person is able to receive some type of communication, I=20 > >>expect that that > >>type of communication would actually work when I use it. >=20 > With high probability. There are no guarantees with presence. For=20 > instance see my mention above of codecs. >=20 > > Exactly right. If you are an application who does not=20 > necessarily aim for interoperability, but still uses sip:,=20 > INVITE etc., you should be able to explicitely say so. >=20 > And you can, without a special notion of service. >=20 > >>>For this kind of=20 > >>>reasons there should be careful text about when to use=20 > >>>service-id in the first place, and what can be determined from it. > >>> > >>>Does someone think that this is an absolutely bad idea? If=20 > >>>so, how would you envision solving the issues discussed above? >=20 > I still don't buy this. >=20 > >>I think more care should be taken in mapping SIP UA=20 > >>capabilities into actual > >>services. That is not so clear to me! > >=20 > > The idea is nice, but I don't see a problem in _addition_=20 > defining the application with something like=20 > "com.openmobilealliance.ptt" or "com.nokia.ptt", if that kind=20 > of profile would have more meaning than the list of characteristics. >=20 > I am still opposed to defining an attribute with no semantics. > We have been around this so many times that I am quite=20 > certain that it=20 > will never be possible to get a useful agreement on what=20 > "service" means. >=20 > If it is introduced, I expect it to have problems like those=20 > of the INFO=20 > method. (The arguments for introducing it seem similar.) >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 03:47:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17022; Fri, 24 Sep 2004 03:47:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAkuu-00044s-Mx; Fri, 24 Sep 2004 03:54:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAkmo-0008Ao-K5; Fri, 24 Sep 2004 03:46:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAklv-0007wu-Em for simple@megatron.ietf.org; Fri, 24 Sep 2004 03:45:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16929 for ; Fri, 24 Sep 2004 03:45:38 -0400 (EDT) Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAkso-00042x-OS for simple@ietf.org; Fri, 24 Sep 2004 03:52:50 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i8O7j5DD006154 for ; Fri, 24 Sep 2004 09:45:07 +0200 Received: from bruc100e.sbs.be (bruc100e.sbs.be [193.210.175.22]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i8O7j4Sn006247 for ; Fri, 24 Sep 2004 09:45:04 +0200 Received: by bruc100e.sbs.be with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Sep 2004 09:44:13 +0200 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F1958B57D9@hrtades7.atea.be> From: Helsen Frank To: "'simple@ietf.org'" Date: Fri, 24 Sep 2004 09:44:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: [Simple] Extend UA Capabiity Extension to PIDF X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 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="===============1566132748==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1566132748== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4A20A.6448CF84" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4A20A.6448CF84 Content-Type: text/plain Hello, At this moment, draft-ietf-simple-prescaps-ext-01 does not provide a way to indicate to the server which client the user uses. I can imagine that an operator has specific client capabilities he would like to know (e.g. java virtual machine version, screen size). When including this client information, the server could retrieve the client capabilities from his e.g. his DB. With this extension, the operator has control over the client information and is not dependend on the information the client provides to him. Next example shows a possible extension Siemens CX65 2.103564 Regards, Frank ------_=_NextPart_001_01C4A20A.6448CF84 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Extend UA Capabiity Extension to PIDF

Hello,


At this moment, = draft-ietf-simple-prescaps-ext-01 does not provide a way to indicate to = the server which client the user uses.  I can imagine that an = operator has specific client capabilities he would like to know (e.g. = java virtual machine version, screen size).  When including this = client information, the server could retrieve the client capabilities = from his e.g. his DB.  With this extension, the operator has = control over the client information and is not dependend on the = information the client provides to him. 

Next example shows a possible = extension

<ClientInfo>
        <Manufacturor> Siemens = </Manufacturor>
        <Model> CX65 </Model>
        <Version>2.103564</Version>
</ClientInfo>

Regards,

Frank


------_=_NextPart_001_01C4A20A.6448CF84-- --===============1566132748== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1566132748==-- From simple-bounces@ietf.org Fri Sep 24 04:39:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20363; Fri, 24 Sep 2004 04:39:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAljR-0005Ah-Nc; Fri, 24 Sep 2004 04:47:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAlba-0006zw-0F; Fri, 24 Sep 2004 04:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAlZN-0006hl-5i for simple@megatron.ietf.org; Fri, 24 Sep 2004 04:36:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20097 for ; Fri, 24 Sep 2004 04:36:43 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAlgK-00056W-8s for simple@ietf.org; Fri, 24 Sep 2004 04:43:56 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8O8aaL22742; Fri, 24 Sep 2004 11:36:36 +0300 (EET DST) X-Scanned: Fri, 24 Sep 2004 11:36:07 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i8O8a7NW028556; Fri, 24 Sep 2004 11:36:07 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00GAAUYZ; Fri, 24 Sep 2004 11:36:05 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8O8a0S22112; Fri, 24 Sep 2004 11:36:00 +0300 (EET DST) Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 24 Sep 2004 11:35:47 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 24 Sep 2004 11:35:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Strength of XML validity requirements in SIMPLE documents Date: Fri, 24 Sep 2004 11:35:46 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B640@esebe056.ntc.nokia.com> Thread-Topic: [Simple] Strength of XML validity requirements in SIMPLE documents Thread-Index: AcShbQcnlN5d4vEjQt6USAzxkzvJ4QApCrZg To: X-OriginalArrivalTime: 24 Sep 2004 08:35:46.0780 (UTC) FILETIME=[7CF521C0:01C4A211] X-Spam-Score: 0.3 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Content-Transfer-Encoding: quoted-printable I'm ok with MAY. It is probably more suitable than the MUST. A consumer = can choose not to validate the XML document and it could only hurt = itself by not doing so. If there are no objections or further suggestions, I'll take this text. Regards, Hisham > -----Original Message----- > From: ext Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: 23.September.2004 15:56 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Strength of XML validity requirements in SIMPLE > documents >=20 >=20 > Hi Hisham, >=20 > For my money, your statements are roughly right. The only=20 > concern I have is > the bit where it says: "...consumer MUST validate...". It's=20 > probably not > the intent, but there's a potential implication that the IETF=20 > is saying that > consumers must run a separate validation exercise on the received data > (rather than say implicitly validating while the application=20 > interprets the > data, in which case they may only end up validating the parts=20 > of the data > they are interested in). It sounds like the IETF is saying how people > should build their devices which traditionally they haven't=20 > done. It's > probably not a big issue, but a possible re-wording is:- >=20 > "The XML document received by a consumer MUST be valid according the > schemas, including extension schemas, the consumer has access=20 > to that are > applicable to this XML document. The consumer MAY validate=20 > the received XML > document against such schemas, and MAY reject the XML document if such > validation is not successful." >=20 > I'll leave it to you. >=20 > Pete. > -- > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Pete Cordell > Tech-Know-Ware > pete(at)tech-know-ware.com > http://www.tech-know-ware.com > http://www.xml2cpp.com - Now Available > +44 1473 635863 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > ----- Original Message -----=20 > From: > To: ; > Cc: ; ;=20 > ; > > Sent: Wednesday, September 22, 2004 9:54 AM > Subject: RE: [Simple] Strength of XML validity requirements in SIMPLE > documents >=20 >=20 > How does this proposal sound (for the filter drafts): >=20 > In the format document, the following text appears: The XML=20 > document MUST be > well-formed and MUST be valid according to schemas, including=20 > extensions > schemas, available to the validater and applicable to the XML=20 > document. >=20 > In the functionality draft: The creator MUST ensure that the=20 > XML document is > well-formed and valid. The creator MUST NOT insert any=20 > extension elements or > attributes into the XML document unless it has access to the extension > schema and can validate the XML document. The XML document=20 > consumer MUST > validate the XML document according the schemas, including extension > schemas, it has access to that are applicable to this XML document. >=20 > For pidf, the second part might be slightly different since=20 > the creator of > the document can be the compositor and the compositor can=20 > create a presence > XML document by aggregating tuples that contain extensions that the > compositor is unaware of. Perhaps something can go in the=20 > Date Model draft > discussing this. >=20 > Regards, > Hisham >=20 >=20 >=20 > > -----Original Message----- > > From: simple-bounces@ietf.org > > [mailto:simple-bounces@ietf.org]On Behalf > > Of ext Pekka Pessi > > Sent: 20.September.2004 14:36 > > To: Jonathan Rosenberg > > Cc: Pessi Pekka (Nokia-NRC/Helsinki); Urpalainen Jari > > (Nokia-NRC/Helsinki); simple@ietf.org; Robert Sparks > > Subject: Re: [Simple] Strength of XML validity requirements=20 > in SIMPLE > > documents > > > > > > Jonathan Rosenberg writes: > > >I'm saying that a document of type application/pidf+xml > > could be valid > > >against the PIDF schema, but it contains extensions (which > > are allowed in > > >the pidf schema), and those extensions make use of elements > > defined in > > >another schema. However, those elements are not valid > > according to that > > >other schema. > > > > >In this case, do we consider this document "valid"? > > > > Term valid has at least three different senses with the XML: > > > > 1) > > > > W3C defines that an XML document is valid when it has a DTD and > > the document complies with the constraints set forth in DTD. > > > > That is not what we want. No for presence, no "MUST be > > valid", please. > > > > (When RFC 3863 says that the application/pidf+xml document MUST > > be well-formed and SHOULD be valid, I guess it just says that > > extensions are allowed, even if they are not shown in the DTD.) > > > > 2) > > > > XML schema specification uses a bit different terminology. Schemas > > don't specify documents, but trees (item and all its descendants). > > You can assess validity of a particular tree, for instance, all > > the XML stuff within element. The validator can also > > skip certain elements (like the wildcard elements used for > > extending pidf). So, validator can return different results: tree > > and items within it are fully validated, partially validated, or > > not validated at all. Also each, item within the tree are valid or > > invalid or their validity is not known. > > > > I'd say that the XML document is schema-valid if its root element > > is fully validated and it and all its descendants are valid. This > > is not the official definition, however. > > > > This is unfeasible for the intermediate nodes (or processes), too. > > Unless the node knows the schema (and semantics) of all the > > extensions, it cannot assess the validity of composed or filtered > > documents. I think filtering and composing is precisely the things > > that we want to do in the server nodes. > > > > I can also imagine some applications that would just use existing > > presence service, just add their non-standard application-specific > > status in the published presence document. Now imagine two of > > those applications running on the same node. > > > > 3) > > > > Beside validity assessment, XML schema specification has the > > concept of "local schema-validity", too: > > > > > > > > I must admit that I don't fully understand what this > > means, but I have a good hunch that it is what most of us > > want. ;) > > > > A element or attribute is valid if it satisfies the constraints > > set by the XML schema. So, element is valid, if it > > contains entity attribute, zero or more elements, then > > zero or more elements and after then something wildcarded > > stuff (I guess that is anything else but pidf-namespace stuff). I > > don't understand how the datatype checking of evil types like > > xs:ID or xs:IDREF is done when the "local schema-validity" is > > determined. I *guess* that ID/IDREF attribute in tuple is valid if > > its value is syntactically correct. Like id=3D"_123" is valid but, > > id=3D"123" is not. No check for all id's within a document/item and > > all of its descendats is required. > > > > So, if we have a application/pidf+xml document, we can simply say > > that it MUST conform to its schema and other requirements set > > forth in RFC 3863. If we want to be more verbose, we could say > > that the root node in the document MUST be partially or fully > > validated and none of the validated nodes MUST NOT be invalid. Or > > we could invent our own term and say that documents MUST be > > locally-schema-valid with the schema XXX. > > > > --Pekka > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 05:36:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24269; Fri, 24 Sep 2004 05:36:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAmc6-0006BZ-H3; Fri, 24 Sep 2004 05:43:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAmPY-0005P6-4T; Fri, 24 Sep 2004 05:30:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAmLR-0004qn-0e for simple@megatron.ietf.org; Fri, 24 Sep 2004 05:26:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23536 for ; Fri, 24 Sep 2004 05:26:23 -0400 (EDT) Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAmSO-00061E-7e for simple@ietf.org; Fri, 24 Sep 2004 05:33:37 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i8O9PuDD016704 for ; Fri, 24 Sep 2004 11:25:56 +0200 Received: from bruc100e.sbs.be (bruc100e.sbs.be [193.210.175.22]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i8O9PsSm019748 for ; Fri, 24 Sep 2004 11:25:54 +0200 Received: by bruc100e.sbs.be with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Sep 2004 11:25:02 +0200 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F1956921A0@hrtades7.atea.be> From: Goeman Stefan To: "'simple@ietf.org'" Subject: RE: [Simple] Presence Authorization Rules Date: Fri, 24 Sep 2004 11:25:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Hello, Comments inline. Greetings, Stefan. > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: donderdag 23 september 2004 19:16 > To: Goeman Stefan; 'simple@ietf.org' > Subject: RE: [Simple] Presence Authorization Rules > > > # hi stefan, > > # please see my comments inline. > > Hello All, > > I have been reading the draft on Presence Authorization > Rules, and also the > draft draft-ietf-geopriv-common-policy. > I have some remarks (otherwise I would not mail of course). > > First of all, the draft on Presence Authorization Rules contracts the > geopriv draft, at least in one place. > In Section 3.2 on Actions, values are given to block, > confirm, ... . If you > have two rules for the same entity and you combine them > according to the > combining rules as explained in the geopriv draft you end up with the > highest value. > # to be more precise the combining permissions algorithms is > applicable if > two or more rules fire. Yes, I understand that, and indeed you need to do something to resolve conflicts. > > Yet, in this case the highest value is the least privacy > preserving. This > is in contradiction with the statement on page 21 of the > geopriv draft: > > "Furthermore, permissions and the meaning of their values > MUST be defined in > such a way that the usage of combining rules CR1, CR2, and CR3 always > preserves or increases the level of privacy protection for the PT". > > One can argue what is wrong here. Personally, I think the > statement in the > geopriv draft will not really work well (see also below). > > # what would happen if jonathan changes the values > corresponding to the > listed actions from > > Block (0) > Confirm (1) > Polite-block (2) > Allow (3) > > # to the following values: > > Block (3) > Confirm (2) > Polite-block (1) > Allow (0) > > # now assume that one rule with allow(0) and another one with block(3) > fires. the combining permissions algorithm would result in a block(3) > action. > > # are you more happy with this result? > In theory, this would be OK. However, I am afraid it is a little bit counter-intuitive. Suppose you have to groups (and groups make sense, certainly on the terminal), friends and colleagues, and one person would be in both groups. In this case you would have two rules for this person. Suppose that when "not at work" you block everything for colleagues, and you still allow some things to be seen for friends. In this case, with the changes proposed above, would be blocked. This I find counter-intuitive. I still believe that it comes from combining positive (permit) rules, while the end result will be less than the origination rules. That is what the statement in geopriv says; and that is what I find counter-intuitive. Or, to put it simpler, suppose you have no rules. Then nothing is visible to other users. Then, you introduce one rule for one person, and something becomes visible for that person. You introduce a second rule for the same person, which results in decreasing the visibility again. > > Additionally, wouldn't it also be nice if one could group > people into a > class of people and define a rule for that class of people. > For example, you > could have a class of friends, family, colleagues and define > a rule each of > this class. The problem know arises that one person could belong to > different groups. Then again, the statement in the geopriv > draft will not > work well. > # grouping people together can be solved on a user interface > basis. There is > not necessarily a need to specify groups in the policies > itself (except if > you want to reduce the bandwidth consumption). > I don't think that is completely true. It goes further than just the user interface. Suppose you have your buddy list, which also resides in the network (see draft on resource lists). The buddy list is partitioned in several groups, i.e. friends, family, ... . In your authorization policies, you would have a rule for friends, family, ... . In this case, when a subscribe arrives, the policy server should resolve the friends, family, and other groups, by contacting the buddy list server, into the real entities before you can find matching rules. I can understand that you have objections to this practice, but it has advantages. If I add an entry in one of my groups (friends, family, ...), I don't have to change my policy rules. I don't see how you could solve that only based on grouping people on the user interface; in this case, I believe you also have to change you policy rules. > ~snip~ > > # ciao > # hannes > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 05:42:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24861; Fri, 24 Sep 2004 05:42:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAmiN-0006Kl-RB; Fri, 24 Sep 2004 05:50:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAmZ9-0006ew-5j; Fri, 24 Sep 2004 05:40:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAmYI-0006S2-7m for simple@megatron.ietf.org; Fri, 24 Sep 2004 05:39:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24508 for ; Fri, 24 Sep 2004 05:39:40 -0400 (EDT) Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAmfF-0006FI-KQ for simple@ietf.org; Fri, 24 Sep 2004 05:46:54 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i8O9cxDD018065 for ; Fri, 24 Sep 2004 11:39:04 +0200 Received: from bruc100e.sbs.be (bruc100e.sbs.be [193.210.175.22]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i8O9cvSm021581 for ; Fri, 24 Sep 2004 11:38:57 +0200 Received: by bruc100e.sbs.be with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Sep 2004 11:38:05 +0200 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F1956921A2@hrtades7.atea.be> From: Goeman Stefan To: "'simple@ietf.org'" Subject: RE: [Simple] Presence Authorization Rules Date: Fri, 24 Sep 2004 11:38:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Hello All, I forgot to mention something. We are talking about policies, but we are not talking about policy enforcement (or maybe I missed that), which I believe is also important. It does not make sense to block certain forms of communication from watchers, that when they try that form of communication anyhow, that they would succeed. This would be very annoying for the presentity. Greetings, Stefan. > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: donderdag 23 september 2004 19:16 > To: Goeman Stefan; 'simple@ietf.org' > Subject: RE: [Simple] Presence Authorization Rules > > > # hi stefan, > > # please see my comments inline. > > Hello All, > > I have been reading the draft on Presence Authorization > Rules, and also the > draft draft-ietf-geopriv-common-policy. > I have some remarks (otherwise I would not mail of course). > > First of all, the draft on Presence Authorization Rules contracts the > geopriv draft, at least in one place. > In Section 3.2 on Actions, values are given to block, > confirm, ... . If you > have two rules for the same entity and you combine them > according to the > combining rules as explained in the geopriv draft you end up with the > highest value. > # to be more precise the combining permissions algorithms is > applicable if > two or more rules fire. > > Yet, in this case the highest value is the least privacy > preserving. This > is in contradiction with the statement on page 21 of the > geopriv draft: > > "Furthermore, permissions and the meaning of their values > MUST be defined in > such a way that the usage of combining rules CR1, CR2, and CR3 always > preserves or increases the level of privacy protection for the PT". > > One can argue what is wrong here. Personally, I think the > statement in the > geopriv draft will not really work well (see also below). > > # what would happen if jonathan changes the values > corresponding to the > listed actions from > > Block (0) > Confirm (1) > Polite-block (2) > Allow (3) > > # to the following values: > > Block (3) > Confirm (2) > Polite-block (1) > Allow (0) > > # now assume that one rule with allow(0) and another one with block(3) > fires. the combining permissions algorithm would result in a block(3) > action. > > # are you more happy with this result? > > > Additionally, wouldn't it also be nice if one could group > people into a > class of people and define a rule for that class of people. > For example, you > could have a class of friends, family, colleagues and define > a rule each of > this class. The problem know arises that one person could belong to > different groups. Then again, the statement in the geopriv > draft will not > work well. > # grouping people together can be solved on a user interface > basis. There is > not necessarily a need to specify groups in the policies > itself (except if > you want to reduce the bandwidth consumption). > > ~snip~ > > # ciao > # hannes > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 07:46:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02844; Fri, 24 Sep 2004 07:46:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAoeD-0008IP-23; Fri, 24 Sep 2004 07:53:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAoW3-0007c5-CR; Fri, 24 Sep 2004 07:45:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAoRa-0006g3-Jb for simple@megatron.ietf.org; Fri, 24 Sep 2004 07:40:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02380 for ; Fri, 24 Sep 2004 07:40:53 -0400 (EDT) Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAoYT-0008C0-Ab for simple@ietf.org; Fri, 24 Sep 2004 07:48:08 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i8OBeCDD028896 for ; Fri, 24 Sep 2004 13:40:12 +0200 Received: from bruc100e.sbs.be (bruc100e.sbs.be [193.210.175.22]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i8OBeCZ9002856 for ; Fri, 24 Sep 2004 13:40:12 +0200 Received: by bruc100e.sbs.be with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Sep 2004 13:39:24 +0200 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F1956921A5@hrtades7.atea.be> From: Goeman Stefan To: "'simple@ietf.org'" Subject: RE: [Simple] Presence Data Model: Identifying services Date: Fri, 24 Sep 2004 13:40:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e47b908cbd1247f22e7953a41f1c4c6 Hello All, I would like to add the following questions/problems to the discussion. How will a presence document be presented to an end-user. Personally, I don't think it makes much sense to present a "raw" presence document, like the one on page 26 of the Presence Data Model draft, to the end-user. In the end, people would like to see on their device: "I can contact person X via email, voice-call, IM, ...". I don't think they would like to see things like: "I can contact person X via SIP". I believe that 99.99% of the world does not know what SIP is, yet everybody (well ...) knows what email is. The point I want to make is that some entity has to process a presence document in a way that it can be presented to an end-user in an meaningful manner. My first guess was that a device could the transformation of the "raw" presence document. Device know which applications they are currently running. So, there should be no problem here. On second thought, I realized that there is one problem: How will this work together with the Authorization rules. Here, again, you have to present the authorization rules in a meaningful manner (via some front end user interface). If I am correct, the idea is to retrieve the authorization rules via XCAP from the policy server, make some changes and provide the changes back to the policy server via XCAP. Yet, the policy server is not aware of any services like IM, voice call, ... . So, again, the device should make this mapping. This works well if you only use one device. But, if you use more than one device, with different capabilities and services, it does not work anymore. A device can't say something meaningful over a service it does not support. Consequently, you can not edit every aspect of the authorization rules on your device. I think this is problematic, and I don't see a good solution right know. Greetings, Stefan. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: donderdag 23 september 2004 17:47 > To: Markus.Isomaki@nokia.com > Cc: Goeman Stefan; simple@ietf.org > Subject: Re: [Simple] Presence Data Model: Identifying services > > > I have comments both to Markus' original posting and to the ensuing > discussion. So I will just insert inline in the latest > response I have. > > Paul > > Markus.Isomaki@nokia.com wrote: > > Hi Stefan, > > > > Comments back to you inline. > > > > (Yes, I absolutely agree with you on the usefulness of the > Presence Data Model draft and that it should have been the > starting point, at least right after PIDF.) > > > > > >>-----Original Message----- > >>From: simple-bounces@ietf.org > >>[mailto:simple-bounces@ietf.org]On Behalf > >>Of ext Goeman Stefan > >>Sent: 23 September, 2004 14:42 > >>To: 'simple@ietf.org' > >>Subject: RE: [Simple] Presence Data Model: Identifying services > >> > >> > >>Hello, > >> > >>Comments inline > >> > >>P.S.: In general, I find the Presence Data model draft a good > >>document. This > >>is how things should have started in the first place. > >> > >>Greetings, > >>Stefan. > >> > >> > >>>-----Original Message----- > >>>From: simple-bounces@ietf.org > >>>[mailto:simple-bounces@ietf.org] On Behalf Of > >> > >>Markus.Isomaki@nokia.com > >> > >>>Sent: donderdag 23 september 2004 10:10 > >>>To: simple@ietf.org > >>>Subject: [Simple] Presence Data Model: Identifying services > >>> > >>> > >>>Hi all, > >>> > >>>I have a comment on Presence Data Model draft about the > >>>identification/characterization of services. (I know this has > >>>been discussed for a while already, but I still think the > >>>current way is somewhat unadequate.) > >>> > >>>The current Data Model draft says: > >>> > >>> In this model, services are not explicitly enumerated. That is, > >>> there is no "service" attribute with values of "ptt" or > >>>"telephony". > >>> Rather, the service is identified in one of two ways. In > >>>many cases, > >>> the URI scheme is a clear indicator of service. An "sms" > >>>URI clearly > >>> indicates SMS, and a "tel" URI clearly indicates > >>>telephony. > > I don't find the scheme as clearcut as that. I don't think one should > assume "tel" indicates telephony. It perhaps does imply > reachability via > various telephony protocols for purpose of voice > communications, but is > not exclusive to that. If the tel: URI can be mapped to a sip > endpoint > and protocol, then non-voice, non-telephony capabilities are > not excluded. > > For instance, it may prove convenient to publish a tel URI for a sip > endpoint that is capable of both voice and IM. Then calls via > the PSTN > will work, calls from a sip audio phone will work, calls from another > voice+im client will have access to voice and IM. > > >>> For some > >>> URIs, there may be many services available, for example, > >> > >>SIP. For > >> > >>> those services, each service has a set of > >> > >>characteristics, each of > >> > >>> which has a well-defined meaning, such that a system can > >>> unequivocally determine whether or not the service has that > >>> characteristic. This is discussed in more detail in [5]. > >>> > >>>I agree that the contact URI scheme is the most important > >>>piece of information to distinguish what is the "service". > >>>(There are some gaps here too, since e.g. the URI schemes for > >>>SMS or MMS do not even exist, and there may be other non-IETF > >>>protocols that face the same problem.) However, I'm not > >>>convinced that listing the signaling/media characteristics of > >>>the end-point or service really gives enough information to > >>>the watcher to really determine if it can communicate with > >>>the advertised service/application. > >>> > >>>The refenced draft [5] has a following example: > >>> > >>>5.6 Walkie-talkie > >>> > >>> The walkie-talkie service allows real-time voice communication > >>> between participants. Only one participant can speak at a > >>>time; that > >>> is, communication is half-duplex. Typically, > >> > >>participants press a > >> > >>> button to indicate that they are ready to speak, although other > >>> mechanism (e.g. voice activation) are occasionally used. > >>> > >>> Support for the Walkie-Talkie service can be deduced by > >>>observing the > >>> presence of a contact URI with a scheme of "sip:", > >> > >>associated with > >> > >>> the following minimal set of capabilities: > >>> half INVITE,ACK,BYE,CANCEL > >>> > >>>Presumably this is the same as the service sometimes called > >>>Push-to-Talk (PTT, PoC). The concrete problem is that there > >>>are several _non-interworking_ variants of this service, that > >>>still all would match the characteristics listed above, as > >>>the _SIP_ part might still be standard, at least for some > >>>methods etc. But still the communication would fail even if > >>>the tuple looks OK. > >> > >>I don't think I understand you here. I would expect that if > >>both end-point > >>SIP US support exactly the same methods, the SIP UA should > >>also be able to > >>handle those SIP method. Or, to phase it in another way, both > >>end-point > >>should be able to communicate with each other only based on > >>using these > >>capabilities. > >> > > > > > > To some extent that might be possible, but there might be > differences e.g. in floor control etc., which make the > service still practically unusable, which means that the > presence document shouldn't give the impression that the > communication will work. Obviously it is possible to list all > those additional characteristics as well (and this might be a > good idea too), but for instance if presence of a network > game is published, it is easier to _explicitely_ tell what > the game is by providing some sort of unique id which would > be only meaningful to those similar game clients. > > > >>>(Also if I saw the characteristics above, > >>>I could as well determine that they describe normal VoIP > >>>application running in (very) some old PC with half-duplex > >>>audio drivers, so I claim the service description is hard to > >>>make unambiguous in the first place.) > > I think the goal should be that all of these are at least minimally > interoperable. I ought to be able to call a PTT contact from > a regular > voice phone and have *something* reasonable happen. (Maybe it is just > oneway voice, with the non-ptt caller never getting the > floor, but that > may be better than nothing. > > I think the real problem in this case is not with the capability > approach. It is that the 'duplex' capability is > underspecified. There is > no explanation of how a pair of half duplex endpoints (or one > half-duplex and one full-duplex endpoint) agree on who can talk. > > In the case of the 'voice' capability, it is understood that > having both > endpoints support voice isn't enough to support > communication. There is > an SDP negotiation of codecs, etc. that either succeeds or > fails. There > should be something similar for half-duplex. > > >>I also have the impression that it will be difficult to > determine the > >>services merely based on the SIP methods (and ...) supported > >>by the SIP UA. > >>It possibly might mean that the SIP-based ptt-service on my > >>mobile phone > >>might be mapped onto some communication service on your PC. > >>Then, I wonder > >>who will be responsible for such kind of mapping? Only the > >>end terminals, or > >>is support from the network, presence server, necessary? And, > >>how will one > >>service in one domain be mapped into a service in another > >>domain? I believe > >>there are some open issues here. > > The intent is that capabilities have common meanings in all > domains, so > they don't need to be mapped. I don't see why there should be any > binding between services and domains. > > In the general case one should assume that there are devices > of widely > varying capabilities in every domain, and that they know best > what they > are capable of. So the device should be the one deciding if a contact > with and advertised set of capabilties is something it wants > to attempt > communication with. > > In some environment where there is an intermediary in front > of a device > that understands the device and acts on its behalf, then I suppose it > could make these decisions. But I would consider that the odd case. > > > I think that it is fully OK to describe some rather simple > things using characteristics, but in many cases applications > are more complex. > > Clearly we have chosen not to describe capabilities if full detail. > (E.g. we don't publish codec support.) Because of this, there is the > possibility that we make a wrong decision about ability to > communicate > and it doesn't get discovered until we try. > > This is ok when the expected probability of failure is low. (We > generally expect that there will be some codec in common, or that one > end or the other will be able to introduce a transcoder.) > > >>>I think the main point of a service tuple is to give the > >>>watcher enough information to know whether he can really > >>>communicate & interoperate with the advertised service. Given > >>>that many services taht are using SIP also have propritary or > >>>non-SIP features, I don't think the current approach is enough. > > In cases where the existing capabilities aren't sufficient to > ensure a > good probability of communication, then we should indeed > consider adding > additional capabilities. > > But I continue to object to the notion of "service" as the way to do > that, because it conveys no semantics about what the > capability is that > it describes. > > >>Do you have an example of a service that uses SIP and also has non > >>SIP-features? If your service also uses non-SIP features, > you can not > >>determine the type of service by only looking at the SIP > capabilities > >>supported by the SIP UA. Some indication of that non-SIP > >>feature should also > >>be present in the presence document. > >> > > > > > > True, and since some of those non-SIP features might not be > based on (IETF) standards, it might be good to have the > possibility for the developers of such applications to have a > short cut of saying what the app really is, rather than > having to list characteristics. In the end, some applications > are really not even meant to work with any other than the > exactly same application, for instance some networking games. > > If the intent is to define a closed world, where > interoperability is not > even considered a desirable feature, then I agree. I think that may > indeed be the case for proprietary games. > > But for something like PTT, while it might be in the best interest of > the maker of a particular PTT solution to keep it closed, I > don't think > it is in the best interest of society or the IETF that this > happen. This > is precisely the forum in which we try to prevent that from happening. > > >>>Of course each of these proprietary services are allowed to > >>>define additional status or tuple-level extensions to PIDF. > >> > >>Yes, you can always extend the PIDF. My comment here is that > >>this might lead > >>to an "explosion" of applications or services. It will > >>certainly not help > >>interoperability. > > My point precisely. > > > And who would standardize such characteristic definitions. > It has already taken a couple of years to standardize even > "prescaps", which is just a starting point. > > > > > >>>However, I would like to have some kind of "service > >>>identifier" as part of the basic framework so that this could > >>>be done in a consistent manner. I think it would help > >>>especially in making of authorization and composition rules > >>>more simple. The current "class" attribute is way too > >>loosely defined. > >> > >>>So the concrete proposal is to include in RPID a "service id" > >>>element that would have a vendor-specific namespace, similar > >>>to e.g. vendor-specific XCAP AUIDs. So for instance the > >>>SIP-based PTT app from vendor xyz.com would have, e.g. > >>>com.xyz.ptt > >>>while the PTT app compliant with OMA would have, e.g. > >>>com.openmobilealliance.ptt > > I am not fond of this solution. Done this way, we have defined an > element that has no semantics at all, only syntax. > > I would rather see vendor specific extensions to PIDF. At > least then the > people that support an extension will understand what it means. > > But I would rather see people come forward and do the hard work of > publicly defining new capabilities so that independent > implementations > can use them in an interoperable way. > > >>In general, I could agree with that approach. However, I > >>don't see a reason > >>why the vendor specific SIP-based PTT should be different > >>from the OMA based > >>PTT. Simply define one PTT, based on the SIP UA capabilities. > >> > > > > > > Well, for instance Nokia has a prorietary PTT application, > which uses SIP INVITE etc., so users are essentially > addressed with sip: URI. However, it has some floor control, > media etc. features which make it basically non-interoperable > with clients that are not specifically following that > proprietary spec. > > This is a problem, not a good thing. I realize it has to > happen as part > of the development process, but the goal should be to get out > of it as > fast as possible. > > I would hope that endpoints supporting this would be > described as well > as possible using existing capabilities, and that a > reasonable effort be > made to do something reasonable when some other sip device connects. > > If you really can't deal with a regular voice caller at all, then I > would suggest, as a transitional step, saying that you don't support > voice, and then advertising some proprietary capability as an > alternative to voice. > > > OMA PTT is closer to standard IETF SIP. Unless there is > some conversion, it does not work with Nokia PTT directly. > There should be some way for distinguishing these two in a > presence document, so that there won't be confusion. I think > the current idea is to do some kind of proprietary PIDF > extensions, but in my opinion a standard XML element in RPID > to tell this kind of information would be better, also for > the purposes of authorization rule making. > > See above for what I think you could do for now. The same issues may > apply to OMA PTT, and a similar solution could be applied to it. > > Hopefully somebody will come up with a PTT that can be dealt > with more > gracefully. I think that work should be done on better defining > half-duplex, so that it can be used in conjunction with voice to > describe PTT. But it may just turn out to be the wrong thing. > Maybe we > need a "floor-control" capability. > > >>>in _addition_ to describing sip:, half-duplex audio, and the > >>>supported methods. Now: > >>>1.) Watcher having one of those apps could see right away > >>>whether it is possible to communicate > >>>2.) Composer getting PUBLISHes from 2 sources could > >>>immediately know that they are from a similar app > >>>3.) The app could set its authorization rules using the unique id. > >>> > >>>The main downside I can see in this approach that if there > >>>are two different proprietary apps that indeed could > >>>communicate at least partially, the watcher might make a > >>>conclusion that communication is not possible baed on > >>>different service-id. > > This is my concern as well. > > >>> However, in this case the watcher still > >>>would have the characteristics visible and could determine > >>>that some interworking could be achieved. > >> > >>Personally, I don't think it is a good idea that an end-user > >>should make > >>such decission. If I get a presence document that indicates > >>that another > >>person is able to receive some type of communication, I > >>expect that that > >>type of communication would actually work when I use it. > > With high probability. There are no guarantees with presence. For > instance see my mention above of codecs. > > > Exactly right. If you are an application who does not > necessarily aim for interoperability, but still uses sip:, > INVITE etc., you should be able to explicitely say so. > > And you can, without a special notion of service. > > >>>For this kind of > >>>reasons there should be careful text about when to use > >>>service-id in the first place, and what can be determined from it. > >>> > >>>Does someone think that this is an absolutely bad idea? If > >>>so, how would you envision solving the issues discussed above? > > I still don't buy this. > > >>I think more care should be taken in mapping SIP UA > >>capabilities into actual > >>services. That is not so clear to me! > > > > The idea is nice, but I don't see a problem in _addition_ > defining the application with something like > "com.openmobilealliance.ptt" or "com.nokia.ptt", if that kind > of profile would have more meaning than the list of characteristics. > > I am still opposed to defining an attribute with no semantics. > We have been around this so many times that I am quite > certain that it > will never be possible to get a useful agreement on what > "service" means. > > If it is introduced, I expect it to have problems like those > of the INFO > method. (The arguments for introducing it seem similar.) > > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 08:40:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06761; Fri, 24 Sep 2004 08:40:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CApUb-0000xY-Ns; Fri, 24 Sep 2004 08:48:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CApMH-000768-T9; Fri, 24 Sep 2004 08:39:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CApLN-0006yj-NT for simple@megatron.ietf.org; Fri, 24 Sep 2004 08:38:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06613 for ; Fri, 24 Sep 2004 08:38:32 -0400 (EDT) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CApSM-0000vM-TF for simple@ietf.org; Fri, 24 Sep 2004 08:45:47 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8OCbnL19299; Fri, 24 Sep 2004 15:37:49 +0300 (EET DST) X-Scanned: Fri, 24 Sep 2004 15:37:27 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i8OCbRGn030792; Fri, 24 Sep 2004 15:37:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00PEkScf; Fri, 24 Sep 2004 15:37:25 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8OCbDY25985; Fri, 24 Sep 2004 15:37:13 +0300 (EET DST) Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 24 Sep 2004 15:37:05 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 24 Sep 2004 15:37:05 +0300 Received: ESEBE054.NOE.Nokia.com 172.21.143.44 from 172.21.39.126 172.21.39.126 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost by ESEBE054.NOE.Nokia.com; 24 Sep 2004 15:37:04 +0300 Subject: Re: [Simple] Presence Data Model: Identifying services From: Aki Niemi To: ext Paul Kyzivat In-Reply-To: <4152EFED.9030206@cisco.com> References: <4152EFED.9030206@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1096029424.6605.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 24 Sep 2004 15:37:04 +0300 X-OriginalArrivalTime: 24 Sep 2004 12:37:05.0532 (UTC) FILETIME=[32F75BC0:01C4A233] X-Spam-Score: 0.0 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e Content-Transfer-Encoding: 7bit Cc: SIMPLE WG , Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 Content-Transfer-Encoding: 7bit On Thu, 2004-09-23 at 18:46, ext Paul Kyzivat wrote: > I don't find the scheme as clearcut as that. I don't think one should > assume "tel" indicates telephony. It perhaps does imply reachability via > various telephony protocols for purpose of voice communications, but is > not exclusive to that. If the tel: URI can be mapped to a sip endpoint > and protocol, then non-voice, non-telephony capabilities are not excluded. Hmm... If the scheme is that ambiguous, then perhaps its definition needs to improve. > For instance, it may prove convenient to publish a tel URI for a sip > endpoint that is capable of both voice and IM. Then calls via the PSTN > will work, calls from a sip audio phone will work, calls from another > voice+im client will have access to voice and IM. IMO the most obvious solution here is that if the endpoint wants to advertize services other than (or in addition to) telephony, it publishes a SIP or IM tuple as well as a tel tuple. Is there a reason this would not work? Cheers, Aki > >>> For some > >>> URIs, there may be many services available, for example, > >> > >>SIP. For > >> > >>> those services, each service has a set of > >> > >>characteristics, each of > >> > >>> which has a well-defined meaning, such that a system can > >>> unequivocally determine whether or not the service has that > >>> characteristic. This is discussed in more detail in [5]. > >>> > >>>I agree that the contact URI scheme is the most important > >>>piece of information to distinguish what is the "service". > >>>(There are some gaps here too, since e.g. the URI schemes for > >>>SMS or MMS do not even exist, and there may be other non-IETF > >>>protocols that face the same problem.) However, I'm not > >>>convinced that listing the signaling/media characteristics of > >>>the end-point or service really gives enough information to > >>>the watcher to really determine if it can communicate with > >>>the advertised service/application. > >>> > >>>The refenced draft [5] has a following example: > >>> > >>>5.6 Walkie-talkie > >>> > >>> The walkie-talkie service allows real-time voice communication > >>> between participants. Only one participant can speak at a > >>>time; that > >>> is, communication is half-duplex. Typically, > >> > >>participants press a > >> > >>> button to indicate that they are ready to speak, although other > >>> mechanism (e.g. voice activation) are occasionally used. > >>> > >>> Support for the Walkie-Talkie service can be deduced by > >>>observing the > >>> presence of a contact URI with a scheme of "sip:", > >> > >>associated with > >> > >>> the following minimal set of capabilities: > >>> half INVITE,ACK,BYE,CANCEL > >>> > >>>Presumably this is the same as the service sometimes called > >>>Push-to-Talk (PTT, PoC). The concrete problem is that there > >>>are several _non-interworking_ variants of this service, that > >>>still all would match the characteristics listed above, as > >>>the _SIP_ part might still be standard, at least for some > >>>methods etc. But still the communication would fail even if > >>>the tuple looks OK. > >> > >>I don't think I understand you here. I would expect that if > >>both end-point > >>SIP US support exactly the same methods, the SIP UA should > >>also be able to > >>handle those SIP method. Or, to phase it in another way, both > >>end-point > >>should be able to communicate with each other only based on > >>using these > >>capabilities. > >> > > > > > > To some extent that might be possible, but there might be differences e.g. in floor control etc., which make the service still practically unusable, which means that the presence document shouldn't give the impression that the communication will work. Obviously it is possible to list all those additional characteristics as well (and this might be a good idea too), but for instance if presence of a network game is published, it is easier to _explicitely_ tell what the game is by providing some sort of unique id which would be only meaningful to those similar game clients. > > > >>>(Also if I saw the characteristics above, > >>>I could as well determine that they describe normal VoIP > >>>application running in (very) some old PC with half-duplex > >>>audio drivers, so I claim the service description is hard to > >>>make unambiguous in the first place.) > > I think the goal should be that all of these are at least minimally > interoperable. I ought to be able to call a PTT contact from a regular > voice phone and have *something* reasonable happen. (Maybe it is just > oneway voice, with the non-ptt caller never getting the floor, but that > may be better than nothing. > > I think the real problem in this case is not with the capability > approach. It is that the 'duplex' capability is underspecified. There is > no explanation of how a pair of half duplex endpoints (or one > half-duplex and one full-duplex endpoint) agree on who can talk. > > In the case of the 'voice' capability, it is understood that having both > endpoints support voice isn't enough to support communication. There is > an SDP negotiation of codecs, etc. that either succeeds or fails. There > should be something similar for half-duplex. > > >>I also have the impression that it will be difficult to determine the > >>services merely based on the SIP methods (and ...) supported > >>by the SIP UA. > >>It possibly might mean that the SIP-based ptt-service on my > >>mobile phone > >>might be mapped onto some communication service on your PC. > >>Then, I wonder > >>who will be responsible for such kind of mapping? Only the > >>end terminals, or > >>is support from the network, presence server, necessary? And, > >>how will one > >>service in one domain be mapped into a service in another > >>domain? I believe > >>there are some open issues here. > > The intent is that capabilities have common meanings in all domains, so > they don't need to be mapped. I don't see why there should be any > binding between services and domains. > > In the general case one should assume that there are devices of widely > varying capabilities in every domain, and that they know best what they > are capable of. So the device should be the one deciding if a contact > with and advertised set of capabilties is something it wants to attempt > communication with. > > In some environment where there is an intermediary in front of a device > that understands the device and acts on its behalf, then I suppose it > could make these decisions. But I would consider that the odd case. > > > I think that it is fully OK to describe some rather simple things using characteristics, but in many cases applications are more complex. > > Clearly we have chosen not to describe capabilities if full detail. > (E.g. we don't publish codec support.) Because of this, there is the > possibility that we make a wrong decision about ability to communicate > and it doesn't get discovered until we try. > > This is ok when the expected probability of failure is low. (We > generally expect that there will be some codec in common, or that one > end or the other will be able to introduce a transcoder.) > > >>>I think the main point of a service tuple is to give the > >>>watcher enough information to know whether he can really > >>>communicate & interoperate with the advertised service. Given > >>>that many services taht are using SIP also have propritary or > >>>non-SIP features, I don't think the current approach is enough. > > In cases where the existing capabilities aren't sufficient to ensure a > good probability of communication, then we should indeed consider adding > additional capabilities. > > But I continue to object to the notion of "service" as the way to do > that, because it conveys no semantics about what the capability is that > it describes. > > >>Do you have an example of a service that uses SIP and also has non > >>SIP-features? If your service also uses non-SIP features, you can not > >>determine the type of service by only looking at the SIP capabilities > >>supported by the SIP UA. Some indication of that non-SIP > >>feature should also > >>be present in the presence document. > >> > > > > > > True, and since some of those non-SIP features might not be based on (IETF) standards, it might be good to have the possibility for the developers of such applications to have a short cut of saying what the app really is, rather than having to list characteristics. In the end, some applications are really not even meant to work with any other than the exactly same application, for instance some networking games. > > If the intent is to define a closed world, where interoperability is not > even considered a desirable feature, then I agree. I think that may > indeed be the case for proprietary games. > > But for something like PTT, while it might be in the best interest of > the maker of a particular PTT solution to keep it closed, I don't think > it is in the best interest of society or the IETF that this happen. This > is precisely the forum in which we try to prevent that from happening. > > >>>Of course each of these proprietary services are allowed to > >>>define additional status or tuple-level extensions to PIDF. > >> > >>Yes, you can always extend the PIDF. My comment here is that > >>this might lead > >>to an "explosion" of applications or services. It will > >>certainly not help > >>interoperability. > > My point precisely. > > > And who would standardize such characteristic definitions. It has already taken a couple of years to standardize even "prescaps", which is just a starting point. > > > > > >>>However, I would like to have some kind of "service > >>>identifier" as part of the basic framework so that this could > >>>be done in a consistent manner. I think it would help > >>>especially in making of authorization and composition rules > >>>more simple. The current "class" attribute is way too > >>loosely defined. > >> > >>>So the concrete proposal is to include in RPID a "service id" > >>>element that would have a vendor-specific namespace, similar > >>>to e.g. vendor-specific XCAP AUIDs. So for instance the > >>>SIP-based PTT app from vendor xyz.com would have, e.g. > >>>com.xyz.ptt > >>>while the PTT app compliant with OMA would have, e.g. > >>>com.openmobilealliance.ptt > > I am not fond of this solution. Done this way, we have defined an > element that has no semantics at all, only syntax. > > I would rather see vendor specific extensions to PIDF. At least then the > people that support an extension will understand what it means. > > But I would rather see people come forward and do the hard work of > publicly defining new capabilities so that independent implementations > can use them in an interoperable way. > > >>In general, I could agree with that approach. However, I > >>don't see a reason > >>why the vendor specific SIP-based PTT should be different > >>from the OMA based > >>PTT. Simply define one PTT, based on the SIP UA capabilities. > >> > > > > > > Well, for instance Nokia has a prorietary PTT application, which uses SIP INVITE etc., so users are essentially addressed with sip: URI. However, it has some floor control, media etc. features which make it basically non-interoperable with clients that are not specifically following that proprietary spec. > > This is a problem, not a good thing. I realize it has to happen as part > of the development process, but the goal should be to get out of it as > fast as possible. > > I would hope that endpoints supporting this would be described as well > as possible using existing capabilities, and that a reasonable effort be > made to do something reasonable when some other sip device connects. > > If you really can't deal with a regular voice caller at all, then I > would suggest, as a transitional step, saying that you don't support > voice, and then advertising some proprietary capability as an > alternative to voice. > > > OMA PTT is closer to standard IETF SIP. Unless there is some conversion, it does not work with Nokia PTT directly. There should be some way for distinguishing these two in a presence document, so that there won't be confusion. I think the current idea is to do some kind of proprietary PIDF extensions, but in my opinion a standard XML element in RPID to tell this kind of information would be better, also for the purposes of authorization rule making. > > See above for what I think you could do for now. The same issues may > apply to OMA PTT, and a similar solution could be applied to it. > > Hopefully somebody will come up with a PTT that can be dealt with more > gracefully. I think that work should be done on better defining > half-duplex, so that it can be used in conjunction with voice to > describe PTT. But it may just turn out to be the wrong thing. Maybe we > need a "floor-control" capability. > > >>>in _addition_ to describing sip:, half-duplex audio, and the > >>>supported methods. Now: > >>>1.) Watcher having one of those apps could see right away > >>>whether it is possible to communicate > >>>2.) Composer getting PUBLISHes from 2 sources could > >>>immediately know that they are from a similar app > >>>3.) The app could set its authorization rules using the unique id. > >>> > >>>The main downside I can see in this approach that if there > >>>are two different proprietary apps that indeed could > >>>communicate at least partially, the watcher might make a > >>>conclusion that communication is not possible baed on > >>>different service-id. > > This is my concern as well. > > >>> However, in this case the watcher still > >>>would have the characteristics visible and could determine > >>>that some interworking could be achieved. > >> > >>Personally, I don't think it is a good idea that an end-user > >>should make > >>such decission. If I get a presence document that indicates > >>that another > >>person is able to receive some type of communication, I > >>expect that that > >>type of communication would actually work when I use it. > > With high probability. There are no guarantees with presence. For > instance see my mention above of codecs. > > > Exactly right. If you are an application who does not necessarily aim for interoperability, but still uses sip:, INVITE etc., you should be able to explicitely say so. > > And you can, without a special notion of service. > > >>>For this kind of > >>>reasons there should be careful text about when to use > >>>service-id in the first place, and what can be determined from it. > >>> > >>>Does someone think that this is an absolutely bad idea? If > >>>so, how would you envision solving the issues discussed above? > > I still don't buy this. > > >>I think more care should be taken in mapping SIP UA > >>capabilities into actual > >>services. That is not so clear to me! > > > > The idea is nice, but I don't see a problem in _addition_ defining the application with something like "com.openmobilealliance.ptt" or "com.nokia.ptt", if that kind of profile would have more meaning than the list of characteristics. > > I am still opposed to defining an attribute with no semantics. > We have been around this so many times that I am quite certain that it > will never be possible to get a useful agreement on what "service" means. > > If it is introduced, I expect it to have problems like those of the INFO > method. (The arguments for introducing it seem similar.) > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 09:49:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11249; Fri, 24 Sep 2004 09:49:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAqZC-00024i-7q; Fri, 24 Sep 2004 09:56:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAqNi-0002ss-In; Fri, 24 Sep 2004 09:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAqJq-0002F2-0Q for simple@megatron.ietf.org; Fri, 24 Sep 2004 09:41:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10785 for ; Fri, 24 Sep 2004 09:41:00 -0400 (EDT) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAqQp-0001xF-2W for simple@ietf.org; Fri, 24 Sep 2004 09:48:16 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8ODesL21443; Fri, 24 Sep 2004 16:40:54 +0300 (EET DST) X-Scanned: Fri, 24 Sep 2004 16:40:34 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i8ODeY2Q014217; Fri, 24 Sep 2004 16:40:34 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Jm1pKg; Fri, 24 Sep 2004 16:40:32 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8ODeVY19705; Fri, 24 Sep 2004 16:40:31 +0300 (EET DST) Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 24 Sep 2004 16:40:26 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe021.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 24 Sep 2004 16:40:24 +0300 Received: ESEBE054.NOE.Nokia.com 172.21.143.44 from 172.21.39.126 172.21.39.126 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost by ESEBE054.NOE.Nokia.com; 24 Sep 2004 16:40:23 +0300 Subject: Re: [Simple] Extend UA Capabiity Extension to PIDF From: Aki Niemi To: ext Helsen Frank In-Reply-To: <57FD2C3A246F76438CA6FDAD8FE9F1958B57D9@hrtades7.atea.be> References: <57FD2C3A246F76438CA6FDAD8FE9F1958B57D9@hrtades7.atea.be> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1096033223.6605.88.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 24 Sep 2004 16:40:23 +0300 X-OriginalArrivalTime: 24 Sep 2004 13:40:24.0434 (UTC) FILETIME=[0B49CD20:01C4A23C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Hi, The primary consumer of presence documents is a presence watcher. And it seems this information wouldn't be all that useful to most if not all watchers. What is the actual scenario where the server would need this information? Because in many cases, the User-Agent header field in SIP is supposed to carry this sort of information already. Cheers, Aki On Fri, 2004-09-24 at 10:44, ext Helsen Frank wrote: > Hello, > > > At this moment, draft-ietf-simple-prescaps-ext-01 does not provide a > way to indicate to the server which client the user uses. I can > imagine that an operator has specific client capabilities he would > like to know (e.g. java virtual machine version, screen size). When > including this client information, the server could retrieve the > client capabilities from his e.g. his DB. With this extension, the > operator has control over the client information and is not dependend > on the information the client provides to him. > > Next example shows a possible extension > > > Siemens > CX65 > 2.103564 > > > Regards, > > Frank > > > > > ______________________________________________________________________ > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 10:05:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12593; Fri, 24 Sep 2004 10:05:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAqoo-0002NG-IN; Fri, 24 Sep 2004 10:13:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAqcx-0005bv-J8; Fri, 24 Sep 2004 10:00:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAqbp-0004zZ-If for simple@megatron.ietf.org; Fri, 24 Sep 2004 09:59:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12048 for ; Fri, 24 Sep 2004 09:59:36 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAqin-0002Gj-DO for simple@ietf.org; Fri, 24 Sep 2004 10:06:52 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 24 Sep 2004 09:59:04 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8ODx17A012399; Fri, 24 Sep 2004 09:59:01 -0400 (EDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALU66140; Fri, 24 Sep 2004 09:59:00 -0400 (EDT) Message-ID: <41542824.1010000@cisco.com> Date: Fri, 24 Sep 2004 09:59:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] Presence Data Model: Identifying services References: <4152EFED.9030206@cisco.com> <1096029424.6605.18.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4cbeb0f20efb229aa93fae1468d20275 Content-Transfer-Encoding: 7bit Cc: SIMPLE WG , Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 715d0e6950aaebd45af78ef9318d0186 Content-Transfer-Encoding: 7bit Aki Niemi wrote: > On Thu, 2004-09-23 at 18:46, ext Paul Kyzivat wrote: > >>I don't find the scheme as clearcut as that. I don't think one should >>assume "tel" indicates telephony. It perhaps does imply reachability via >>various telephony protocols for purpose of voice communications, but is >>not exclusive to that. If the tel: URI can be mapped to a sip endpoint >>and protocol, then non-voice, non-telephony capabilities are not excluded. > > Hmm... If the scheme is that ambiguous, then perhaps its definition > needs to improve. Why? There is no particular reason why tel: should mean voice. We don't restrict sip: that way, and http: doesn't say much about what you can do either. (I can use http to exchange html, vxml, xcap, etc.) AFAIK, tel: is an addressing format and namespace. The following is from draft-ietf-iptel-rfc2806bis-09: The "tel" URI telephone number is not restricted in the type of termination point it refers to. The termination point can be in the public telephone network, a private telephone network or the Internet. The termination point can be fixed or wireless and address a fixed wired, mobile or nomadic terminal. The terminal addressed can support any electronic communication service (ECS) including voice, data and fax. >>For instance, it may prove convenient to publish a tel URI for a sip >>endpoint that is capable of both voice and IM. Then calls via the PSTN >>will work, calls from a sip audio phone will work, calls from another >>voice+im client will have access to voice and IM. > > IMO the most obvious solution here is that if the endpoint wants to > advertize services other than (or in addition to) telephony, it > publishes a SIP or IM tuple as well as a tel tuple. Is there a reason > this would not work? I don't see a problem here, and so I don't feel a need for a solution. I agree that other address forms are probably desirable in this case, for a variety of reasons. But that doesn't mean we should automatically assume tel: implies voice telephony and only that. One place where this situation may well come up is when the tel: uri is used as the presentity address. (Something that should be ok, and makes sense to use if you are a client and that is all you have.) It may be that the user doesn't want to expose device addresses, and so provides only the presentity address back as the contact in the tuple(s). Paul > Cheers, > Aki > > >> >>> For some >> >>>>> URIs, there may be many services available, for example, >>>> >>>>SIP. For >>>> >>>> >>>>> those services, each service has a set of >>>> >>>>characteristics, each of >>>> >>>> >>>>> which has a well-defined meaning, such that a system can >>>>> unequivocally determine whether or not the service has that >>>>> characteristic. This is discussed in more detail in [5]. >>>>> >>>>>I agree that the contact URI scheme is the most important >>>>>piece of information to distinguish what is the "service". >>>>>(There are some gaps here too, since e.g. the URI schemes for >>>>>SMS or MMS do not even exist, and there may be other non-IETF >>>>>protocols that face the same problem.) However, I'm not >>>>>convinced that listing the signaling/media characteristics of >>>>>the end-point or service really gives enough information to >>>>>the watcher to really determine if it can communicate with >>>>>the advertised service/application. >>>>> >>>>>The refenced draft [5] has a following example: >>>>> >>>>>5.6 Walkie-talkie >>>>> >>>>> The walkie-talkie service allows real-time voice communication >>>>> between participants. Only one participant can speak at a >>>>>time; that >>>>> is, communication is half-duplex. Typically, >>>> >>>>participants press a >>>> >>>> >>>>> button to indicate that they are ready to speak, although other >>>>> mechanism (e.g. voice activation) are occasionally used. >>>>> >>>>> Support for the Walkie-Talkie service can be deduced by >>>>>observing the >>>>> presence of a contact URI with a scheme of "sip:", >>>> >>>>associated with >>>> >>>> >>>>> the following minimal set of capabilities: >>>>> half INVITE,ACK,BYE,CANCEL >>>>> >>>>>Presumably this is the same as the service sometimes called >>>>>Push-to-Talk (PTT, PoC). The concrete problem is that there >>>>>are several _non-interworking_ variants of this service, that >>>>>still all would match the characteristics listed above, as >>>>>the _SIP_ part might still be standard, at least for some >>>>>methods etc. But still the communication would fail even if >>>>>the tuple looks OK. >>>> >>>>I don't think I understand you here. I would expect that if >>>>both end-point >>>>SIP US support exactly the same methods, the SIP UA should >>>>also be able to >>>>handle those SIP method. Or, to phase it in another way, both >>>>end-point >>>>should be able to communicate with each other only based on >>>>using these >>>>capabilities. >>>> >>> >>> >>>To some extent that might be possible, but there might be differences e.g. in floor control etc., which make the service still practically unusable, which means that the presence document shouldn't give the impression that the communication will work. Obviously it is possible to list all those additional characteristics as well (and this might be a good idea too), but for instance if presence of a network game is published, it is easier to _explicitely_ tell what the game is by providing some sort of unique id which would be only meaningful to those similar game clients. >> >> > >> >>>>>(Also if I saw the characteristics above, >>>>>I could as well determine that they describe normal VoIP >>>>>application running in (very) some old PC with half-duplex >>>>>audio drivers, so I claim the service description is hard to >>>>>make unambiguous in the first place.) >>>> >>I think the goal should be that all of these are at least minimally >>interoperable. I ought to be able to call a PTT contact from a regular >>voice phone and have *something* reasonable happen. (Maybe it is just >>oneway voice, with the non-ptt caller never getting the floor, but that >>may be better than nothing. >> >>I think the real problem in this case is not with the capability >>approach. It is that the 'duplex' capability is underspecified. There is >>no explanation of how a pair of half duplex endpoints (or one >>half-duplex and one full-duplex endpoint) agree on who can talk. >> >>In the case of the 'voice' capability, it is understood that having both >>endpoints support voice isn't enough to support communication. There is >>an SDP negotiation of codecs, etc. that either succeeds or fails. There >>should be something similar for half-duplex. >> >> >>>>I also have the impression that it will be difficult to determine the >>>>services merely based on the SIP methods (and ...) supported >>>>by the SIP UA. >>>>It possibly might mean that the SIP-based ptt-service on my >>>>mobile phone >>>>might be mapped onto some communication service on your PC. >>>>Then, I wonder >>>>who will be responsible for such kind of mapping? Only the >>>>end terminals, or >>>>is support from the network, presence server, necessary? And, >>>>how will one >>>>service in one domain be mapped into a service in another >>>>domain? I believe >>>>there are some open issues here. >>> >>The intent is that capabilities have common meanings in all domains, so >>they don't need to be mapped. I don't see why there should be any >>binding between services and domains. >> >>In the general case one should assume that there are devices of widely >>varying capabilities in every domain, and that they know best what they >>are capable of. So the device should be the one deciding if a contact >>with and advertised set of capabilties is something it wants to attempt >>communication with. >> >>In some environment where there is an intermediary in front of a device >>that understands the device and acts on its behalf, then I suppose it >>could make these decisions. But I would consider that the odd case. >> >> >>>I think that it is fully OK to describe some rather simple things using characteristics, but in many cases applications are more complex. >> >>Clearly we have chosen not to describe capabilities if full detail. >>(E.g. we don't publish codec support.) Because of this, there is the >>possibility that we make a wrong decision about ability to communicate >>and it doesn't get discovered until we try. >> >>This is ok when the expected probability of failure is low. (We >>generally expect that there will be some codec in common, or that one >>end or the other will be able to introduce a transcoder.) >> >> >>>>>I think the main point of a service tuple is to give the >>>>>watcher enough information to know whether he can really >>>>>communicate & interoperate with the advertised service. Given >>>>>that many services taht are using SIP also have propritary or >>>>>non-SIP features, I don't think the current approach is enough. >>>> >>In cases where the existing capabilities aren't sufficient to ensure a >>good probability of communication, then we should indeed consider adding >>additional capabilities. >> >>But I continue to object to the notion of "service" as the way to do >>that, because it conveys no semantics about what the capability is that >>it describes. >> >> >>>>Do you have an example of a service that uses SIP and also has non >>>>SIP-features? If your service also uses non-SIP features, you can not >>>>determine the type of service by only looking at the SIP capabilities >>>>supported by the SIP UA. Some indication of that non-SIP >>>>feature should also >>>>be present in the presence document. >>>> >>> >>> >>>True, and since some of those non-SIP features might not be based on (IETF) standards, it might be good to have the possibility for the developers of such applications to have a short cut of saying what the app really is, rather than having to list characteristics. In the end, some applications are really not even meant to work with any other than the exactly same application, for instance some networking games. >> >>If the intent is to define a closed world, where interoperability is not >>even considered a desirable feature, then I agree. I think that may >>indeed be the case for proprietary games. >> >>But for something like PTT, while it might be in the best interest of >>the maker of a particular PTT solution to keep it closed, I don't think >>it is in the best interest of society or the IETF that this happen. This >>is precisely the forum in which we try to prevent that from happening. >> >> >>>>>Of course each of these proprietary services are allowed to >>>>>define additional status or tuple-level extensions to PIDF. >>>> >>>>Yes, you can always extend the PIDF. My comment here is that >>>>this might lead >>>>to an "explosion" of applications or services. It will >>>>certainly not help >>>>interoperability. >>> >>My point precisely. >> >> >>>And who would standardize such characteristic definitions. It has already taken a couple of years to standardize even "prescaps", which is just a starting point. >>> >>> >>> >>>>>However, I would like to have some kind of "service >>>>>identifier" as part of the basic framework so that this could >>>>>be done in a consistent manner. I think it would help >>>>>especially in making of authorization and composition rules >>>>>more simple. The current "class" attribute is way too >>>> >>>>loosely defined. >>>> >>>> >>>>>So the concrete proposal is to include in RPID a "service id" >>>>>element that would have a vendor-specific namespace, similar >>>>>to e.g. vendor-specific XCAP AUIDs. So for instance the >>>>>SIP-based PTT app from vendor xyz.com would have, e.g. >>>>>com.xyz.ptt >>>>>while the PTT app compliant with OMA would have, e.g. >>>>>com.openmobilealliance.ptt >>>> >>I am not fond of this solution. Done this way, we have defined an >>element that has no semantics at all, only syntax. >> >>I would rather see vendor specific extensions to PIDF. At least then the >>people that support an extension will understand what it means. >> >>But I would rather see people come forward and do the hard work of >>publicly defining new capabilities so that independent implementations >>can use them in an interoperable way. >> >> >>>>In general, I could agree with that approach. However, I >>>>don't see a reason >>>>why the vendor specific SIP-based PTT should be different >>> >>>>from the OMA based >>> >>>>PTT. Simply define one PTT, based on the SIP UA capabilities. >>>> >>> >>> >>>Well, for instance Nokia has a prorietary PTT application, which uses SIP INVITE etc., so users are essentially addressed with sip: URI. However, it has some floor control, media etc. features which make it basically non-interoperable with clients that are not specifically following that proprietary spec. >> >>This is a problem, not a good thing. I realize it has to happen as part >>of the development process, but the goal should be to get out of it as >>fast as possible. >> >>I would hope that endpoints supporting this would be described as well >>as possible using existing capabilities, and that a reasonable effort be >>made to do something reasonable when some other sip device connects. >> >>If you really can't deal with a regular voice caller at all, then I >>would suggest, as a transitional step, saying that you don't support >>voice, and then advertising some proprietary capability as an >>alternative to voice. >> >> >>>OMA PTT is closer to standard IETF SIP. Unless there is some conversion, it does not work with Nokia PTT directly. There should be some way for distinguishing these two in a presence document, so that there won't be confusion. I think the current idea is to do some kind of proprietary PIDF extensions, but in my opinion a standard XML element in RPID to tell this kind of information would be better, also for the purposes of authorization rule making. >> >>See above for what I think you could do for now. The same issues may >>apply to OMA PTT, and a similar solution could be applied to it. >> >>Hopefully somebody will come up with a PTT that can be dealt with more >>gracefully. I think that work should be done on better defining >>half-duplex, so that it can be used in conjunction with voice to >>describe PTT. But it may just turn out to be the wrong thing. Maybe we >>need a "floor-control" capability. >> >> >>>>>in _addition_ to describing sip:, half-duplex audio, and the >>>>>supported methods. Now: >>>>>1.) Watcher having one of those apps could see right away >>>>>whether it is possible to communicate >>>>>2.) Composer getting PUBLISHes from 2 sources could >>>>>immediately know that they are from a similar app >>>>>3.) The app could set its authorization rules using the unique id. >>>>> >>>>>The main downside I can see in this approach that if there >>>>>are two different proprietary apps that indeed could >>>>>communicate at least partially, the watcher might make a >>>>>conclusion that communication is not possible baed on >>>>>different service-id. >>>> >>This is my concern as well. >> >> >>> However, in this case the watcher still >> >>>>>would have the characteristics visible and could determine >>>>>that some interworking could be achieved. >>>> >>>>Personally, I don't think it is a good idea that an end-user >>>>should make >>>>such decission. If I get a presence document that indicates >>>>that another >>>>person is able to receive some type of communication, I >>>>expect that that >>>>type of communication would actually work when I use it. >>> >>With high probability. There are no guarantees with presence. For >>instance see my mention above of codecs. >> >> >>>Exactly right. If you are an application who does not necessarily aim for interoperability, but still uses sip:, INVITE etc., you should be able to explicitely say so. >> >>And you can, without a special notion of service. >> >> >>>>>For this kind of >>>>>reasons there should be careful text about when to use >>>>>service-id in the first place, and what can be determined from it. >>>>> >>>>>Does someone think that this is an absolutely bad idea? If >>>>>so, how would you envision solving the issues discussed above? >>>> >>I still don't buy this. >> >> >>>>I think more care should be taken in mapping SIP UA >>>>capabilities into actual >>>>services. That is not so clear to me! >>> >>>The idea is nice, but I don't see a problem in _addition_ defining the application with something like "com.openmobilealliance.ptt" or "com.nokia.ptt", if that kind of profile would have more meaning than the list of characteristics. >> >>I am still opposed to defining an attribute with no semantics. >>We have been around this so many times that I am quite certain that it >>will never be possible to get a useful agreement on what "service" means. >> >>If it is introduced, I expect it to have problems like those of the INFO >>method. (The arguments for introducing it seem similar.) >> >> Paul >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 10:27:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15200; Fri, 24 Sep 2004 10:27:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAr9m-0002sD-5G; Fri, 24 Sep 2004 10:34:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAqyF-00065x-4Q; Fri, 24 Sep 2004 10:22:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAquB-00041v-50 for simple@megatron.ietf.org; Fri, 24 Sep 2004 10:18:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14206 for ; Fri, 24 Sep 2004 10:18:33 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAr1A-0002bA-VI for simple@ietf.org; Fri, 24 Sep 2004 10:25:49 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 24 Sep 2004 10:34:36 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8OEI0bx013629; Fri, 24 Sep 2004 10:18:01 -0400 (EDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALU67750; Fri, 24 Sep 2004 10:17:59 -0400 (EDT) Message-ID: <41542C97.7090804@cisco.com> Date: Fri, 24 Sep 2004 10:17:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Goeman Stefan Subject: Re: [Simple] Presence Data Model: Identifying services References: <57FD2C3A246F76438CA6FDAD8FE9F1956921A5@hrtades7.atea.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 04b84659b2acb599bee006e63124a606 Content-Transfer-Encoding: 7bit Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 182294e3fdac3aef093c0503b87ed133 Content-Transfer-Encoding: 7bit Goeman Stefan wrote: > Hello All, > > I would like to add the following questions/problems to the discussion. > > How will a presence document be presented to an end-user. Personally, I > don't think it makes much sense to present a "raw" presence document, like > the one on page 26 of the Presence Data Model draft, to the end-user. Agreed. I don't know of anybody that thinks it should normally be displayed in raw form. (For advanced users, a device with a sufficiently powerful UI could offer something on the order of the "view source" that mail guis often provide.) > In the > end, people would like to see on their device: "I can contact person X via > email, voice-call, IM, ...". I don't think they would like to see things > like: "I can contact person X via SIP". I believe that 99.99% of the world > does not know what SIP is, yet everybody (well ...) knows what email is. Everybody I have spoken to about this seems to imagine some form of iconic interface - similar to but richer than what is provided by common IM clients today for buddy lists. This will of course vary somewhat depending on the capabilities of the client device. For a device with the ui capabilities of a PC, running a client application with multimedia support (voice, video, IM, ...), what I have in mind is something like: - a "list" view with one line per buddy - the list has an icons indicating general availability, idleness, supported media. (This represents an OR of all the tuples.) - this list should have been pruned by the client application, so that it only displays capabilities the client also supports, and only indicated general availability if some supported mode of communication is available. - it would be possible to initiate a call of any supported type(s) by interacting with this single line on the display. The client would then presumably "fork" the call to all compatible tuples. - it should be possible to "expand" the display of a buddy. In the expanded form, there would be one line per tuple. Again these would be iconic. A call to a particular device could be initiated by manipulating one of these. > The point I want to make is that some entity has to process a presence > document in a way that it can be presented to an end-user in an meaningful > manner. Yes, filter and format. > My first guess was that a device could the transformation of the "raw" > presence document. Device know which applications they are currently > running. So, there should be no problem here. > > On second thought, I realized that there is one problem: > How will this work together with the Authorization rules. I think you are imagining a problem here. I don't think it makes much sense for the client to determine authorization, beyond simply being authorized to subscribe to presence. If the PS gives you the info, just display it. The PS can filter out what it thinks you should not see or do. In any case there is no good way for a client to determine if it is permitted to do something, short of trying to do it. Paul > Here, again, you > have to present the authorization rules in a meaningful manner (via some > front end user interface). If I am correct, the idea is to retrieve the > authorization rules via XCAP from the policy server, make some changes and > provide the changes back to the policy server via XCAP. Yet, the policy > server is not aware of any services like IM, voice call, ... . So, again, > the device should make this mapping. This works well if you only use one > device. But, if you use more than one device, with different capabilities > and services, it does not work anymore. A device can't say something > meaningful over a service it does not support. Consequently, you can not > edit every aspect of the authorization rules on your device. I think this is > problematic, and I don't see a good solution right know. > > Greetings, > Stefan. > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: donderdag 23 september 2004 17:47 >>To: Markus.Isomaki@nokia.com >>Cc: Goeman Stefan; simple@ietf.org >>Subject: Re: [Simple] Presence Data Model: Identifying services >> >> >>I have comments both to Markus' original posting and to the ensuing >>discussion. So I will just insert inline in the latest >>response I have. >> >> Paul >> >>Markus.Isomaki@nokia.com wrote: >> >>>Hi Stefan, >>> >>>Comments back to you inline. >>> >>>(Yes, I absolutely agree with you on the usefulness of the >> >>Presence Data Model draft and that it should have been the >>starting point, at least right after PIDF.) >> >>> >>>>-----Original Message----- >>>>From: simple-bounces@ietf.org >>>>[mailto:simple-bounces@ietf.org]On Behalf >>>>Of ext Goeman Stefan >>>>Sent: 23 September, 2004 14:42 >>>>To: 'simple@ietf.org' >>>>Subject: RE: [Simple] Presence Data Model: Identifying services >>>> >>>> >>>>Hello, >>>> >>>>Comments inline >>>> >>>>P.S.: In general, I find the Presence Data model draft a good >>>>document. This >>>>is how things should have started in the first place. >>>> >>>>Greetings, >>>>Stefan. >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: simple-bounces@ietf.org >>>>>[mailto:simple-bounces@ietf.org] On Behalf Of >>>> >>>>Markus.Isomaki@nokia.com >>>> >>>> >>>>>Sent: donderdag 23 september 2004 10:10 >>>>>To: simple@ietf.org >>>>>Subject: [Simple] Presence Data Model: Identifying services >>>>> >>>>> >>>>>Hi all, >>>>> >>>>>I have a comment on Presence Data Model draft about the >>>>>identification/characterization of services. (I know this has >>>>>been discussed for a while already, but I still think the >>>>>current way is somewhat unadequate.) >>>>> >>>>>The current Data Model draft says: >>>>> >>>>> In this model, services are not explicitly enumerated. That is, >>>>> there is no "service" attribute with values of "ptt" or >>>>>"telephony". >>>>> Rather, the service is identified in one of two ways. In >>>>>many cases, >>>>> the URI scheme is a clear indicator of service. An "sms" >>>>>URI clearly >>>>> indicates SMS, and a "tel" URI clearly indicates >>>>>telephony. >>>> >>I don't find the scheme as clearcut as that. I don't think one should >>assume "tel" indicates telephony. It perhaps does imply >>reachability via >>various telephony protocols for purpose of voice >>communications, but is >>not exclusive to that. If the tel: URI can be mapped to a sip >>endpoint >>and protocol, then non-voice, non-telephony capabilities are >>not excluded. >> >>For instance, it may prove convenient to publish a tel URI for a sip >>endpoint that is capable of both voice and IM. Then calls via >>the PSTN >>will work, calls from a sip audio phone will work, calls from another >>voice+im client will have access to voice and IM. >> >> >>> For some >> >>>>> URIs, there may be many services available, for example, >>>> >>>>SIP. For >>>> >>>> >>>>> those services, each service has a set of >>>> >>>>characteristics, each of >>>> >>>> >>>>> which has a well-defined meaning, such that a system can >>>>> unequivocally determine whether or not the service has that >>>>> characteristic. This is discussed in more detail in [5]. >>>>> >>>>>I agree that the contact URI scheme is the most important >>>>>piece of information to distinguish what is the "service". >>>>>(There are some gaps here too, since e.g. the URI schemes for >>>>>SMS or MMS do not even exist, and there may be other non-IETF >>>>>protocols that face the same problem.) However, I'm not >>>>>convinced that listing the signaling/media characteristics of >>>>>the end-point or service really gives enough information to >>>>>the watcher to really determine if it can communicate with >>>>>the advertised service/application. >>>>> >>>>>The refenced draft [5] has a following example: >>>>> >>>>>5.6 Walkie-talkie >>>>> >>>>> The walkie-talkie service allows real-time voice communication >>>>> between participants. Only one participant can speak at a >>>>>time; that >>>>> is, communication is half-duplex. Typically, >>>> >>>>participants press a >>>> >>>> >>>>> button to indicate that they are ready to speak, although other >>>>> mechanism (e.g. voice activation) are occasionally used. >>>>> >>>>> Support for the Walkie-Talkie service can be deduced by >>>>>observing the >>>>> presence of a contact URI with a scheme of "sip:", >>>> >>>>associated with >>>> >>>> >>>>> the following minimal set of capabilities: >>>>> half INVITE,ACK,BYE,CANCEL >>>>> >>>>>Presumably this is the same as the service sometimes called >>>>>Push-to-Talk (PTT, PoC). The concrete problem is that there >>>>>are several _non-interworking_ variants of this service, that >>>>>still all would match the characteristics listed above, as >>>>>the _SIP_ part might still be standard, at least for some >>>>>methods etc. But still the communication would fail even if >>>>>the tuple looks OK. >>>> >>>>I don't think I understand you here. I would expect that if >>>>both end-point >>>>SIP US support exactly the same methods, the SIP UA should >>>>also be able to >>>>handle those SIP method. Or, to phase it in another way, both >>>>end-point >>>>should be able to communicate with each other only based on >>>>using these >>>>capabilities. >>>> >>> >>> >>>To some extent that might be possible, but there might be >> >>differences e.g. in floor control etc., which make the >>service still practically unusable, which means that the >>presence document shouldn't give the impression that the >>communication will work. Obviously it is possible to list all >>those additional characteristics as well (and this might be a >>good idea too), but for instance if presence of a network >>game is published, it is easier to _explicitely_ tell what >>the game is by providing some sort of unique id which would >>be only meaningful to those similar game clients. >> > >> >>>>>(Also if I saw the characteristics above, >>>>>I could as well determine that they describe normal VoIP >>>>>application running in (very) some old PC with half-duplex >>>>>audio drivers, so I claim the service description is hard to >>>>>make unambiguous in the first place.) >>>> >>I think the goal should be that all of these are at least minimally >>interoperable. I ought to be able to call a PTT contact from >>a regular >>voice phone and have *something* reasonable happen. (Maybe it is just >>oneway voice, with the non-ptt caller never getting the >>floor, but that >>may be better than nothing. >> >>I think the real problem in this case is not with the capability >>approach. It is that the 'duplex' capability is >>underspecified. There is >>no explanation of how a pair of half duplex endpoints (or one >>half-duplex and one full-duplex endpoint) agree on who can talk. >> >>In the case of the 'voice' capability, it is understood that >>having both >>endpoints support voice isn't enough to support >>communication. There is >>an SDP negotiation of codecs, etc. that either succeeds or >>fails. There >>should be something similar for half-duplex. >> >> >>>>I also have the impression that it will be difficult to >>> >>determine the >> >>>>services merely based on the SIP methods (and ...) supported >>>>by the SIP UA. >>>>It possibly might mean that the SIP-based ptt-service on my >>>>mobile phone >>>>might be mapped onto some communication service on your PC. >>>>Then, I wonder >>>>who will be responsible for such kind of mapping? Only the >>>>end terminals, or >>>>is support from the network, presence server, necessary? And, >>>>how will one >>>>service in one domain be mapped into a service in another >>>>domain? I believe >>>>there are some open issues here. >>> >>The intent is that capabilities have common meanings in all >>domains, so >>they don't need to be mapped. I don't see why there should be any >>binding between services and domains. >> >>In the general case one should assume that there are devices >>of widely >>varying capabilities in every domain, and that they know best >>what they >>are capable of. So the device should be the one deciding if a contact >>with and advertised set of capabilties is something it wants >>to attempt >>communication with. >> >>In some environment where there is an intermediary in front >>of a device >>that understands the device and acts on its behalf, then I suppose it >>could make these decisions. But I would consider that the odd case. >> >> >>>I think that it is fully OK to describe some rather simple >> >>things using characteristics, but in many cases applications >>are more complex. >> >>Clearly we have chosen not to describe capabilities if full detail. >>(E.g. we don't publish codec support.) Because of this, there is the >>possibility that we make a wrong decision about ability to >>communicate >>and it doesn't get discovered until we try. >> >>This is ok when the expected probability of failure is low. (We >>generally expect that there will be some codec in common, or that one >>end or the other will be able to introduce a transcoder.) >> >> >>>>>I think the main point of a service tuple is to give the >>>>>watcher enough information to know whether he can really >>>>>communicate & interoperate with the advertised service. Given >>>>>that many services taht are using SIP also have propritary or >>>>>non-SIP features, I don't think the current approach is enough. >>>> >>In cases where the existing capabilities aren't sufficient to >>ensure a >>good probability of communication, then we should indeed >>consider adding >>additional capabilities. >> >>But I continue to object to the notion of "service" as the way to do >>that, because it conveys no semantics about what the >>capability is that >>it describes. >> >> >>>>Do you have an example of a service that uses SIP and also has non >>>>SIP-features? If your service also uses non-SIP features, >>> >>you can not >> >>>>determine the type of service by only looking at the SIP >>> >>capabilities >> >>>>supported by the SIP UA. Some indication of that non-SIP >>>>feature should also >>>>be present in the presence document. >>>> >>> >>> >>>True, and since some of those non-SIP features might not be >> >>based on (IETF) standards, it might be good to have the >>possibility for the developers of such applications to have a >>short cut of saying what the app really is, rather than >>having to list characteristics. In the end, some applications >>are really not even meant to work with any other than the >>exactly same application, for instance some networking games. >> >>If the intent is to define a closed world, where >>interoperability is not >>even considered a desirable feature, then I agree. I think that may >>indeed be the case for proprietary games. >> >>But for something like PTT, while it might be in the best interest of >>the maker of a particular PTT solution to keep it closed, I >>don't think >>it is in the best interest of society or the IETF that this >>happen. This >>is precisely the forum in which we try to prevent that from happening. >> >> >>>>>Of course each of these proprietary services are allowed to >>>>>define additional status or tuple-level extensions to PIDF. >>>> >>>>Yes, you can always extend the PIDF. My comment here is that >>>>this might lead >>>>to an "explosion" of applications or services. It will >>>>certainly not help >>>>interoperability. >>> >>My point precisely. >> >> >>>And who would standardize such characteristic definitions. >> >>It has already taken a couple of years to standardize even >>"prescaps", which is just a starting point. >> >>> >>>>>However, I would like to have some kind of "service >>>>>identifier" as part of the basic framework so that this could >>>>>be done in a consistent manner. I think it would help >>>>>especially in making of authorization and composition rules >>>>>more simple. The current "class" attribute is way too >>>> >>>>loosely defined. >>>> >>>> >>>>>So the concrete proposal is to include in RPID a "service id" >>>>>element that would have a vendor-specific namespace, similar >>>>>to e.g. vendor-specific XCAP AUIDs. So for instance the >>>>>SIP-based PTT app from vendor xyz.com would have, e.g. >>>>>com.xyz.ptt >>>>>while the PTT app compliant with OMA would have, e.g. >>>>>com.openmobilealliance.ptt >>>> >>I am not fond of this solution. Done this way, we have defined an >>element that has no semantics at all, only syntax. >> >>I would rather see vendor specific extensions to PIDF. At >>least then the >>people that support an extension will understand what it means. >> >>But I would rather see people come forward and do the hard work of >>publicly defining new capabilities so that independent >>implementations >>can use them in an interoperable way. >> >> >>>>In general, I could agree with that approach. However, I >>>>don't see a reason >>>>why the vendor specific SIP-based PTT should be different >>> >>>>from the OMA based >>> >>>>PTT. Simply define one PTT, based on the SIP UA capabilities. >>>> >>> >>> >>>Well, for instance Nokia has a prorietary PTT application, >> >>which uses SIP INVITE etc., so users are essentially >>addressed with sip: URI. However, it has some floor control, >>media etc. features which make it basically non-interoperable >>with clients that are not specifically following that >>proprietary spec. >> >>This is a problem, not a good thing. I realize it has to >>happen as part >>of the development process, but the goal should be to get out >>of it as >>fast as possible. >> >>I would hope that endpoints supporting this would be >>described as well >>as possible using existing capabilities, and that a >>reasonable effort be >>made to do something reasonable when some other sip device connects. >> >>If you really can't deal with a regular voice caller at all, then I >>would suggest, as a transitional step, saying that you don't support >>voice, and then advertising some proprietary capability as an >>alternative to voice. >> >> >>>OMA PTT is closer to standard IETF SIP. Unless there is >> >>some conversion, it does not work with Nokia PTT directly. >>There should be some way for distinguishing these two in a >>presence document, so that there won't be confusion. I think >>the current idea is to do some kind of proprietary PIDF >>extensions, but in my opinion a standard XML element in RPID >>to tell this kind of information would be better, also for >>the purposes of authorization rule making. >> >>See above for what I think you could do for now. The same issues may >>apply to OMA PTT, and a similar solution could be applied to it. >> >>Hopefully somebody will come up with a PTT that can be dealt >>with more >>gracefully. I think that work should be done on better defining >>half-duplex, so that it can be used in conjunction with voice to >>describe PTT. But it may just turn out to be the wrong thing. >>Maybe we >>need a "floor-control" capability. >> >> >>>>>in _addition_ to describing sip:, half-duplex audio, and the >>>>>supported methods. Now: >>>>>1.) Watcher having one of those apps could see right away >>>>>whether it is possible to communicate >>>>>2.) Composer getting PUBLISHes from 2 sources could >>>>>immediately know that they are from a similar app >>>>>3.) The app could set its authorization rules using the unique id. >>>>> >>>>>The main downside I can see in this approach that if there >>>>>are two different proprietary apps that indeed could >>>>>communicate at least partially, the watcher might make a >>>>>conclusion that communication is not possible baed on >>>>>different service-id. >>>> >>This is my concern as well. >> >> >>> However, in this case the watcher still >> >>>>>would have the characteristics visible and could determine >>>>>that some interworking could be achieved. >>>> >>>>Personally, I don't think it is a good idea that an end-user >>>>should make >>>>such decission. If I get a presence document that indicates >>>>that another >>>>person is able to receive some type of communication, I >>>>expect that that >>>>type of communication would actually work when I use it. >>> >>With high probability. There are no guarantees with presence. For >>instance see my mention above of codecs. >> >> >>>Exactly right. If you are an application who does not >> >>necessarily aim for interoperability, but still uses sip:, >>INVITE etc., you should be able to explicitely say so. >> >>And you can, without a special notion of service. >> >> >>>>>For this kind of >>>>>reasons there should be careful text about when to use >>>>>service-id in the first place, and what can be determined from it. >>>>> >>>>>Does someone think that this is an absolutely bad idea? If >>>>>so, how would you envision solving the issues discussed above? >>>> >>I still don't buy this. >> >> >>>>I think more care should be taken in mapping SIP UA >>>>capabilities into actual >>>>services. That is not so clear to me! >>> >>>The idea is nice, but I don't see a problem in _addition_ >> >>defining the application with something like >>"com.openmobilealliance.ptt" or "com.nokia.ptt", if that kind >>of profile would have more meaning than the list of characteristics. >> >>I am still opposed to defining an attribute with no semantics. >>We have been around this so many times that I am quite >>certain that it >>will never be possible to get a useful agreement on what >>"service" means. >> >>If it is introduced, I expect it to have problems like those >>of the INFO >>method. (The arguments for introducing it seem similar.) >> >> Paul >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 10:40:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16089; Fri, 24 Sep 2004 10:40:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CArM1-00035e-M8; Fri, 24 Sep 2004 10:47:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CArBW-0008Cl-VI; Fri, 24 Sep 2004 10:36:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAr3Q-0006qr-6e for simple@megatron.ietf.org; Fri, 24 Sep 2004 10:28:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15244 for ; Fri, 24 Sep 2004 10:28:06 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CArAO-0002sH-Of for simple@ietf.org; Fri, 24 Sep 2004 10:35:23 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 Sep 2004 07:30:12 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8OERTSI014227; Fri, 24 Sep 2004 07:27:30 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALU68607; Fri, 24 Sep 2004 10:27:30 -0400 (EDT) Message-ID: <41542ED2.2090000@cisco.com> Date: Fri, 24 Sep 2004 10:27:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helsen Frank Subject: Re: [Simple] Extend UA Capabiity Extension to PIDF References: <57FD2C3A246F76438CA6FDAD8FE9F1958B57D9@hrtades7.atea.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Helsen, I don't understand your terminology very well, or what you are trying to achieve. By 'client' I guess you mean a device addressed by a contact in a tuple of the presence document, rather than a subscriber to presence. Is that right? I don't know precisely what role you have in mind for 'operator'. Is it the operator of the presence server itself? Or is it something that is a client of the PS. What is it doing that requires it to know this information? In general the device will probably be publishing its own presence status to the presence server. If so the extension you suggest would simply cause it to push this invariant information over and over. This kind of info can already be polled using OPTIONS. Why isn't that enough? Paul Helsen Frank wrote: > Hello, > > > At this moment, draft-ietf-simple-prescaps-ext-01 does not provide a way > to indicate to the server which client the user uses. I can imagine > that an operator has specific client capabilities he would like to know > (e.g. java virtual machine version, screen size). When including this > client information, the server could retrieve the client capabilities > from his e.g. his DB. With this extension, the operator has control > over the client information and is not dependend on the information the > client provides to him. > > Next example shows a possible extension > > > Siemens > CX65 > 2.103564 > > > Regards, > > Frank > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 10:42:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16239; Fri, 24 Sep 2004 10:42:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CArNt-00038J-UE; Fri, 24 Sep 2004 10:49:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CArCf-0008M7-SU; Fri, 24 Sep 2004 10:37:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAr9W-0007oh-2V for simple@megatron.ietf.org; Fri, 24 Sep 2004 10:34:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15750 for ; Fri, 24 Sep 2004 10:34:24 -0400 (EDT) Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CArGQ-0002ye-76 for simple@ietf.org; Fri, 24 Sep 2004 10:41:40 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i8OEXnDD014533 for ; Fri, 24 Sep 2004 16:33:49 +0200 Received: from bruc100e.sbs.be (bruc100e.sbs.be [193.210.175.22]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i8OEXmZ9025960 for ; Fri, 24 Sep 2004 16:33:48 +0200 Received: by bruc100e.sbs.be with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Sep 2004 16:32:58 +0200 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F1956921A9@hrtades7.atea.be> From: Goeman Stefan To: "'simple@ietf.org'" Subject: RE: [Simple] Presence Data Model: Identifying services Date: Fri, 24 Sep 2004 16:31:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 64592953d6410e1f725ee21266e2f396 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 94ddbad0060c343c23e74ba9bbebbccf Hello, Comments inline. Greetings, Stefan. > > On second thought, I realized that there is one problem: > > How will this work together with the Authorization rules. > > I think you are imagining a problem here. I don't think it makes much > sense for the client to determine authorization, beyond simply being > authorized to subscribe to presence. If the PS gives you the > info, just > display it. The PS can filter out what it thinks you should > not see or do. > I think we are talking about different things here. I was taking about me as presentity managing and editing my own authorization rules. Since my presence information is also "my property" I would expect that I would be able to play the role of a rule maker. Clearly, you have to edit your rules somehow, via some device. > In any case there is no good way for a client to determine if it is > permitted to do something, short of trying to do it. > > Paul > > > Here, again, you > > have to present the authorization rules in a meaningful > manner (via some > > front end user interface). If I am correct, the idea is to > retrieve the > > authorization rules via XCAP from the policy server, make > some changes and > > provide the changes back to the policy server via XCAP. > Yet, the policy > > server is not aware of any services like IM, voice call, > ... . So, again, > > the device should make this mapping. This works well if you > only use one > > device. But, if you use more than one device, with > different capabilities > > and services, it does not work anymore. A device can't say something > > meaningful over a service it does not support. > Consequently, you can not > > edit every aspect of the authorization rules on your > device. I think this is > > problematic, and I don't see a good solution right know. > > > > Greetings, > > Stefan. > > > > > >>-----Original Message----- > >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>Sent: donderdag 23 september 2004 17:47 > >>To: Markus.Isomaki@nokia.com > >>Cc: Goeman Stefan; simple@ietf.org > >>Subject: Re: [Simple] Presence Data Model: Identifying services > >> > >> > >>I have comments both to Markus' original posting and to the ensuing > >>discussion. So I will just insert inline in the latest > >>response I have. > >> > >> Paul > >> > >>Markus.Isomaki@nokia.com wrote: > >> > >>>Hi Stefan, > >>> > >>>Comments back to you inline. > >>> > >>>(Yes, I absolutely agree with you on the usefulness of the > >> > >>Presence Data Model draft and that it should have been the > >>starting point, at least right after PIDF.) > >> > >>> > >>>>-----Original Message----- > >>>>From: simple-bounces@ietf.org > >>>>[mailto:simple-bounces@ietf.org]On Behalf > >>>>Of ext Goeman Stefan > >>>>Sent: 23 September, 2004 14:42 > >>>>To: 'simple@ietf.org' > >>>>Subject: RE: [Simple] Presence Data Model: Identifying services > >>>> > >>>> > >>>>Hello, > >>>> > >>>>Comments inline > >>>> > >>>>P.S.: In general, I find the Presence Data model draft a good > >>>>document. This > >>>>is how things should have started in the first place. > >>>> > >>>>Greetings, > >>>>Stefan. > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: simple-bounces@ietf.org > >>>>>[mailto:simple-bounces@ietf.org] On Behalf Of > >>>> > >>>>Markus.Isomaki@nokia.com > >>>> > >>>> > >>>>>Sent: donderdag 23 september 2004 10:10 > >>>>>To: simple@ietf.org > >>>>>Subject: [Simple] Presence Data Model: Identifying services > >>>>> > >>>>> > >>>>>Hi all, > >>>>> > >>>>>I have a comment on Presence Data Model draft about the > >>>>>identification/characterization of services. (I know this has > >>>>>been discussed for a while already, but I still think the > >>>>>current way is somewhat unadequate.) > >>>>> > >>>>>The current Data Model draft says: > >>>>> > >>>>> In this model, services are not explicitly enumerated. > That is, > >>>>> there is no "service" attribute with values of "ptt" or > >>>>>"telephony". > >>>>> Rather, the service is identified in one of two ways. In > >>>>>many cases, > >>>>> the URI scheme is a clear indicator of service. An "sms" > >>>>>URI clearly > >>>>> indicates SMS, and a "tel" URI clearly indicates > >>>>>telephony. > >>>> > >>I don't find the scheme as clearcut as that. I don't think > one should > >>assume "tel" indicates telephony. It perhaps does imply > >>reachability via > >>various telephony protocols for purpose of voice > >>communications, but is > >>not exclusive to that. If the tel: URI can be mapped to a sip > >>endpoint > >>and protocol, then non-voice, non-telephony capabilities are > >>not excluded. > >> > >>For instance, it may prove convenient to publish a tel URI > for a sip > >>endpoint that is capable of both voice and IM. Then calls via > >>the PSTN > >>will work, calls from a sip audio phone will work, calls > from another > >>voice+im client will have access to voice and IM. > >> > >> >>> For some > >> > >>>>> URIs, there may be many services available, for example, > >>>> > >>>>SIP. For > >>>> > >>>> > >>>>> those services, each service has a set of > >>>> > >>>>characteristics, each of > >>>> > >>>> > >>>>> which has a well-defined meaning, such that a system can > >>>>> unequivocally determine whether or not the service has that > >>>>> characteristic. This is discussed in more detail in [5]. > >>>>> > >>>>>I agree that the contact URI scheme is the most important > >>>>>piece of information to distinguish what is the "service". > >>>>>(There are some gaps here too, since e.g. the URI schemes for > >>>>>SMS or MMS do not even exist, and there may be other non-IETF > >>>>>protocols that face the same problem.) However, I'm not > >>>>>convinced that listing the signaling/media characteristics of > >>>>>the end-point or service really gives enough information to > >>>>>the watcher to really determine if it can communicate with > >>>>>the advertised service/application. > >>>>> > >>>>>The refenced draft [5] has a following example: > >>>>> > >>>>>5.6 Walkie-talkie > >>>>> > >>>>> The walkie-talkie service allows real-time voice communication > >>>>> between participants. Only one participant can speak at a > >>>>>time; that > >>>>> is, communication is half-duplex. Typically, > >>>> > >>>>participants press a > >>>> > >>>> > >>>>> button to indicate that they are ready to speak, although other > >>>>> mechanism (e.g. voice activation) are occasionally used. > >>>>> > >>>>> Support for the Walkie-Talkie service can be deduced by > >>>>>observing the > >>>>> presence of a contact URI with a scheme of "sip:", > >>>> > >>>>associated with > >>>> > >>>> > >>>>> the following minimal set of capabilities: > >>>>> half INVITE,ACK,BYE,CANCEL > >>>>> > >>>>>Presumably this is the same as the service sometimes called > >>>>>Push-to-Talk (PTT, PoC). The concrete problem is that there > >>>>>are several _non-interworking_ variants of this service, that > >>>>>still all would match the characteristics listed above, as > >>>>>the _SIP_ part might still be standard, at least for some > >>>>>methods etc. But still the communication would fail even if > >>>>>the tuple looks OK. > >>>> > >>>>I don't think I understand you here. I would expect that if > >>>>both end-point > >>>>SIP US support exactly the same methods, the SIP UA should > >>>>also be able to > >>>>handle those SIP method. Or, to phase it in another way, both > >>>>end-point > >>>>should be able to communicate with each other only based on > >>>>using these > >>>>capabilities. > >>>> > >>> > >>> > >>>To some extent that might be possible, but there might be > >> > >>differences e.g. in floor control etc., which make the > >>service still practically unusable, which means that the > >>presence document shouldn't give the impression that the > >>communication will work. Obviously it is possible to list all > >>those additional characteristics as well (and this might be a > >>good idea too), but for instance if presence of a network > >>game is published, it is easier to _explicitely_ tell what > >>the game is by providing some sort of unique id which would > >>be only meaningful to those similar game clients. > >> > > >> > >>>>>(Also if I saw the characteristics above, > >>>>>I could as well determine that they describe normal VoIP > >>>>>application running in (very) some old PC with half-duplex > >>>>>audio drivers, so I claim the service description is hard to > >>>>>make unambiguous in the first place.) > >>>> > >>I think the goal should be that all of these are at least minimally > >>interoperable. I ought to be able to call a PTT contact from > >>a regular > >>voice phone and have *something* reasonable happen. (Maybe > it is just > >>oneway voice, with the non-ptt caller never getting the > >>floor, but that > >>may be better than nothing. > >> > >>I think the real problem in this case is not with the capability > >>approach. It is that the 'duplex' capability is > >>underspecified. There is > >>no explanation of how a pair of half duplex endpoints (or one > >>half-duplex and one full-duplex endpoint) agree on who can talk. > >> > >>In the case of the 'voice' capability, it is understood that > >>having both > >>endpoints support voice isn't enough to support > >>communication. There is > >>an SDP negotiation of codecs, etc. that either succeeds or > >>fails. There > >>should be something similar for half-duplex. > >> > >> > >>>>I also have the impression that it will be difficult to > >>> > >>determine the > >> > >>>>services merely based on the SIP methods (and ...) supported > >>>>by the SIP UA. > >>>>It possibly might mean that the SIP-based ptt-service on my > >>>>mobile phone > >>>>might be mapped onto some communication service on your PC. > >>>>Then, I wonder > >>>>who will be responsible for such kind of mapping? Only the > >>>>end terminals, or > >>>>is support from the network, presence server, necessary? And, > >>>>how will one > >>>>service in one domain be mapped into a service in another > >>>>domain? I believe > >>>>there are some open issues here. > >>> > >>The intent is that capabilities have common meanings in all > >>domains, so > >>they don't need to be mapped. I don't see why there should be any > >>binding between services and domains. > >> > >>In the general case one should assume that there are devices > >>of widely > >>varying capabilities in every domain, and that they know best > >>what they > >>are capable of. So the device should be the one deciding if > a contact > >>with and advertised set of capabilties is something it wants > >>to attempt > >>communication with. > >> > >>In some environment where there is an intermediary in front > >>of a device > >>that understands the device and acts on its behalf, then I > suppose it > >>could make these decisions. But I would consider that the odd case. > >> > >> > >>>I think that it is fully OK to describe some rather simple > >> > >>things using characteristics, but in many cases applications > >>are more complex. > >> > >>Clearly we have chosen not to describe capabilities if full detail. > >>(E.g. we don't publish codec support.) Because of this, > there is the > >>possibility that we make a wrong decision about ability to > >>communicate > >>and it doesn't get discovered until we try. > >> > >>This is ok when the expected probability of failure is low. (We > >>generally expect that there will be some codec in common, > or that one > >>end or the other will be able to introduce a transcoder.) > >> > >> > >>>>>I think the main point of a service tuple is to give the > >>>>>watcher enough information to know whether he can really > >>>>>communicate & interoperate with the advertised service. Given > >>>>>that many services taht are using SIP also have propritary or > >>>>>non-SIP features, I don't think the current approach is enough. > >>>> > >>In cases where the existing capabilities aren't sufficient to > >>ensure a > >>good probability of communication, then we should indeed > >>consider adding > >>additional capabilities. > >> > >>But I continue to object to the notion of "service" as the > way to do > >>that, because it conveys no semantics about what the > >>capability is that > >>it describes. > >> > >> > >>>>Do you have an example of a service that uses SIP and also has non > >>>>SIP-features? If your service also uses non-SIP features, > >>> > >>you can not > >> > >>>>determine the type of service by only looking at the SIP > >>> > >>capabilities > >> > >>>>supported by the SIP UA. Some indication of that non-SIP > >>>>feature should also > >>>>be present in the presence document. > >>>> > >>> > >>> > >>>True, and since some of those non-SIP features might not be > >> > >>based on (IETF) standards, it might be good to have the > >>possibility for the developers of such applications to have a > >>short cut of saying what the app really is, rather than > >>having to list characteristics. In the end, some applications > >>are really not even meant to work with any other than the > >>exactly same application, for instance some networking games. > >> > >>If the intent is to define a closed world, where > >>interoperability is not > >>even considered a desirable feature, then I agree. I think that may > >>indeed be the case for proprietary games. > >> > >>But for something like PTT, while it might be in the best > interest of > >>the maker of a particular PTT solution to keep it closed, I > >>don't think > >>it is in the best interest of society or the IETF that this > >>happen. This > >>is precisely the forum in which we try to prevent that from > happening. > >> > >> > >>>>>Of course each of these proprietary services are allowed to > >>>>>define additional status or tuple-level extensions to PIDF. > >>>> > >>>>Yes, you can always extend the PIDF. My comment here is that > >>>>this might lead > >>>>to an "explosion" of applications or services. It will > >>>>certainly not help > >>>>interoperability. > >>> > >>My point precisely. > >> > >> > >>>And who would standardize such characteristic definitions. > >> > >>It has already taken a couple of years to standardize even > >>"prescaps", which is just a starting point. > >> > >>> > >>>>>However, I would like to have some kind of "service > >>>>>identifier" as part of the basic framework so that this could > >>>>>be done in a consistent manner. I think it would help > >>>>>especially in making of authorization and composition rules > >>>>>more simple. The current "class" attribute is way too > >>>> > >>>>loosely defined. > >>>> > >>>> > >>>>>So the concrete proposal is to include in RPID a "service id" > >>>>>element that would have a vendor-specific namespace, similar > >>>>>to e.g. vendor-specific XCAP AUIDs. So for instance the > >>>>>SIP-based PTT app from vendor xyz.com would have, e.g. > >>>>>com.xyz.ptt > >>>>>while the PTT app compliant with OMA would have, e.g. > >>>>>com.openmobilealliance.ptt > >>>> > >>I am not fond of this solution. Done this way, we have defined an > >>element that has no semantics at all, only syntax. > >> > >>I would rather see vendor specific extensions to PIDF. At > >>least then the > >>people that support an extension will understand what it means. > >> > >>But I would rather see people come forward and do the hard work of > >>publicly defining new capabilities so that independent > >>implementations > >>can use them in an interoperable way. > >> > >> > >>>>In general, I could agree with that approach. However, I > >>>>don't see a reason > >>>>why the vendor specific SIP-based PTT should be different > >>> > >>>>from the OMA based > >>> > >>>>PTT. Simply define one PTT, based on the SIP UA capabilities. > >>>> > >>> > >>> > >>>Well, for instance Nokia has a prorietary PTT application, > >> > >>which uses SIP INVITE etc., so users are essentially > >>addressed with sip: URI. However, it has some floor control, > >>media etc. features which make it basically non-interoperable > >>with clients that are not specifically following that > >>proprietary spec. > >> > >>This is a problem, not a good thing. I realize it has to > >>happen as part > >>of the development process, but the goal should be to get out > >>of it as > >>fast as possible. > >> > >>I would hope that endpoints supporting this would be > >>described as well > >>as possible using existing capabilities, and that a > >>reasonable effort be > >>made to do something reasonable when some other sip device connects. > >> > >>If you really can't deal with a regular voice caller at all, then I > >>would suggest, as a transitional step, saying that you > don't support > >>voice, and then advertising some proprietary capability as an > >>alternative to voice. > >> > >> > >>>OMA PTT is closer to standard IETF SIP. Unless there is > >> > >>some conversion, it does not work with Nokia PTT directly. > >>There should be some way for distinguishing these two in a > >>presence document, so that there won't be confusion. I think > >>the current idea is to do some kind of proprietary PIDF > >>extensions, but in my opinion a standard XML element in RPID > >>to tell this kind of information would be better, also for > >>the purposes of authorization rule making. > >> > >>See above for what I think you could do for now. The same > issues may > >>apply to OMA PTT, and a similar solution could be applied to it. > >> > >>Hopefully somebody will come up with a PTT that can be dealt > >>with more > >>gracefully. I think that work should be done on better defining > >>half-duplex, so that it can be used in conjunction with voice to > >>describe PTT. But it may just turn out to be the wrong thing. > >>Maybe we > >>need a "floor-control" capability. > >> > >> > >>>>>in _addition_ to describing sip:, half-duplex audio, and the > >>>>>supported methods. Now: > >>>>>1.) Watcher having one of those apps could see right away > >>>>>whether it is possible to communicate > >>>>>2.) Composer getting PUBLISHes from 2 sources could > >>>>>immediately know that they are from a similar app > >>>>>3.) The app could set its authorization rules using the > unique id. > >>>>> > >>>>>The main downside I can see in this approach that if there > >>>>>are two different proprietary apps that indeed could > >>>>>communicate at least partially, the watcher might make a > >>>>>conclusion that communication is not possible baed on > >>>>>different service-id. > >>>> > >>This is my concern as well. > >> > >> >>> However, in this case the watcher still > >> > >>>>>would have the characteristics visible and could determine > >>>>>that some interworking could be achieved. > >>>> > >>>>Personally, I don't think it is a good idea that an end-user > >>>>should make > >>>>such decission. If I get a presence document that indicates > >>>>that another > >>>>person is able to receive some type of communication, I > >>>>expect that that > >>>>type of communication would actually work when I use it. > >>> > >>With high probability. There are no guarantees with presence. For > >>instance see my mention above of codecs. > >> > >> > >>>Exactly right. If you are an application who does not > >> > >>necessarily aim for interoperability, but still uses sip:, > >>INVITE etc., you should be able to explicitely say so. > >> > >>And you can, without a special notion of service. > >> > >> > >>>>>For this kind of > >>>>>reasons there should be careful text about when to use > >>>>>service-id in the first place, and what can be > determined from it. > >>>>> > >>>>>Does someone think that this is an absolutely bad idea? If > >>>>>so, how would you envision solving the issues discussed above? > >>>> > >>I still don't buy this. > >> > >> > >>>>I think more care should be taken in mapping SIP UA > >>>>capabilities into actual > >>>>services. That is not so clear to me! > >>> > >>>The idea is nice, but I don't see a problem in _addition_ > >> > >>defining the application with something like > >>"com.openmobilealliance.ptt" or "com.nokia.ptt", if that kind > >>of profile would have more meaning than the list of characteristics. > >> > >>I am still opposed to defining an attribute with no semantics. > >>We have been around this so many times that I am quite > >>certain that it > >>will never be possible to get a useful agreement on what > >>"service" means. > >> > >>If it is introduced, I expect it to have problems like those > >>of the INFO > >>method. (The arguments for introducing it seem similar.) > >> > >> Paul > >> > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 11:41:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19125; Fri, 24 Sep 2004 11:41:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsJX-00042a-37; Fri, 24 Sep 2004 11:48:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAs3T-0006tJ-F1; Fri, 24 Sep 2004 11:32:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CArzV-0006KT-BP for simple@megatron.ietf.org; Fri, 24 Sep 2004 11:28:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18550 for ; Fri, 24 Sep 2004 11:28:07 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAs6M-0003p4-0A for simple@ietf.org; Fri, 24 Sep 2004 11:35:24 -0400 Received: from dynamicsoft.com ([63.113.46.44]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8OFRlpl022025; Fri, 24 Sep 2004 11:27:48 -0400 (EDT) Message-ID: <41543CE1.20207@dynamicsoft.com> Date: Fri, 24 Sep 2004 11:27:29 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: [Simple] Presence Data Model: Identifying services References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit inline. Markus.Isomaki@nokia.com wrote: > Hi Stefan, > > Comments back to you inline. > > (Yes, I absolutely agree with you on the usefulness of the Presence > Data Model draft and that it should have been the starting point, at > least right after PIDF.) Thanks! Obviously I agree its a good thing ;) > > To some extent that might be possible, but there might be differences > e.g. in floor control etc., which make the service still practically > unusable, which means that the presence document shouldn't give the > impression that the communication will work. Obviously it is possible > to list all those additional characteristics as well (and this might > be a good idea too), but for instance if presence of a network game > is published, it is easier to _explicitely_ tell what the game is by > providing some sort of unique id which would be only meaningful to > those similar game clients. I think there are two aspects to this. Firstly, I think we have a bunch of "SIP endpoints", like your PTT phone, which use SIP as a core technology, but don't interoperate with any other SIP endpoint. We've designed SIP to *be* interoperable, so if its not, its telling me that your protocol really isn't SIP after all. In such a case, I would suggest you register a new URI scheme for it, for example, ptt:user@domain, to indicate this. I think this is a scheme, since the point of a URI is to provide full context required to communicate. If sip:user@domain isn't providing that context since there are proprietary changes which prevent communication from compliant SIP endpoints, the scheme needs to be changed. That said, there are cases where an endpoint is 100% sip compliant, but still it cannot communicate with another endpoint. Assuming proper behavior in terms of falling back to baseline usages when extensions aren't supported, I can only think of really a small number of reasons why this would happen: 1. Endpoints A and B do not support a common codec for the media types they have in common, 2. Endpoints A and B do not support a common set of media types For the specific case of PTT, where "if you don't support this floor control technique, the call won't be set up", I put that in the first category (cases where its not really SIP). Thats because a SIP endpoint should be able to proceed with a call if extensions or features are not utilized. If you are not doing that because they are essential to the service, then it's something different. The second case above (no common media or codecs) is solved in part in the presence document, where the supported media types are listed. We have elected not to include codecs in presence documents, so that case cannot be detected. Of course, a call can always fail even if there are no protocol interop problems - I may call you, you insist on video, and since I don't do video, you elect not to proceed with the call. That's a **policy** problem, and I do not think it is the role of presence to generally convey the policies which are required to be in place for a call to complete. Perhaps others have different opinions. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 11:55:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20005; Fri, 24 Sep 2004 11:55:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsX4-0004I3-3Y; Fri, 24 Sep 2004 12:02:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsJL-0000K0-2p; Fri, 24 Sep 2004 11:48:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsB2-0007YV-44 for simple@megatron.ietf.org; Fri, 24 Sep 2004 11:40:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19084 for ; Fri, 24 Sep 2004 11:40:01 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsI3-000417-4J for simple@ietf.org; Fri, 24 Sep 2004 11:47:19 -0400 Received: from dynamicsoft.com ([63.113.46.44]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8OFbcpl022062; Fri, 24 Sep 2004 11:37:38 -0400 (EDT) Message-ID: <41543F2A.9070708@dynamicsoft.com> Date: Fri, 24 Sep 2004 11:37:14 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: meaning of tel URI in presence data model, was: Re: [Simple] Presence Data Model: Identifying services References: <4152EFED.9030206@cisco.com> <1096029424.6605.18.camel@localhost.localdomain> <41542824.1010000@cisco.com> In-Reply-To: <41542824.1010000@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: Markus.Isomaki@nokia.com, Aki Niemi , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > > > Aki Niemi wrote: > >> On Thu, 2004-09-23 at 18:46, ext Paul Kyzivat wrote: >> >>> I don't find the scheme as clearcut as that. I don't think one should >>> assume "tel" indicates telephony. It perhaps does imply reachability >>> via various telephony protocols for purpose of voice communications, >>> but is not exclusive to that. If the tel: URI can be mapped to a sip >>> endpoint and protocol, then non-voice, non-telephony capabilities are >>> not excluded. >> >> >> Hmm... If the scheme is that ambiguous, then perhaps its definition >> needs to improve. > > > Why? There is no particular reason why tel: should mean voice. We don't > restrict sip: that way, and http: doesn't say much about what you can do > either. (I can use http to exchange html, vxml, xcap, etc.) > > AFAIK, tel: is an addressing format and namespace. The following is from > draft-ietf-iptel-rfc2806bis-09: > > The "tel" URI telephone number is not restricted in the type of > termination point it refers to. The termination point can be in the > public telephone network, a private telephone network or the > Internet. The termination point can be fixed or wireless and address > a fixed wired, mobile or nomadic terminal. The terminal addressed > can support any electronic communication service (ECS) including > voice, data and fax. Sigh... here is another case where the tel URI's confusion about what it really is, is getting us into trouble. If you think about the tel URI as a urn scheme, whereby resolution to an actual set of communication resources is done using a resolution service (ala DDDS), then it becomes fairly obvious (to me at least) that you would simply never even put that URN into the of a presence document, since it doesnt represent a communications service at all. If anything, it's closer to a presentity identifier. Rather, you would put the individual service URIs that result from the DDDS lookups. However, the tel URI is somewhat schizophrenic. Its not a URN, even though it can use (but doesnt require) URN-like resolution services such as enum. It's like a URN in that it can refer to an abstract name and be resolved to a wealth of different URIs of many different schemes and services. Its unlike a URN in that it is also used to refer to telephone resources, and the implication of the tel URI is that "I can dial this from a PSTN phone or enterprise phone and reach something". In that aspect, its more like a protocol URI. What does this mean for presence? To be honest, in the discussion in the data model draft, I have assumed the protocol URI meaning. That is, it refers to a PSTN (or private network) circuit endpoint, period. That, of course, is a BIG assumption, and something we should discuss. I would propose that we keep this assumption and merely state it. In such a case, it would not make sense for the recipient of a presence document to look up such a tel URI in enum. Rather, it knows its a telephony resource right away and can "dial it". Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 11:57:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20230; Fri, 24 Sep 2004 11:57:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsZE-0004Lb-6n; Fri, 24 Sep 2004 12:05:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsQG-0001eD-M1; Fri, 24 Sep 2004 11:55:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsJL-0000Kg-HP for simple@megatron.ietf.org; Fri, 24 Sep 2004 11:48:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19535 for ; Fri, 24 Sep 2004 11:48:37 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsQM-00048h-So for simple@ietf.org; Fri, 24 Sep 2004 11:55:55 -0400 Received: from dynamicsoft.com ([63.113.46.44]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8OFmLpl022096; Fri, 24 Sep 2004 11:48:21 -0400 (EDT) Message-ID: <415441AE.4070107@dynamicsoft.com> Date: Fri, 24 Sep 2004 11:47:58 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Extend UA Capabiity Extension to PIDF References: <57FD2C3A246F76438CA6FDAD8FE9F1958B57D9@hrtades7.atea.be> <41542ED2.2090000@cisco.com> In-Reply-To: <41542ED2.2090000@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit My guess is that Helsen is looking at something equivalent to the UAProf functions in WAP, which allow a client to push fairly complicated information about itself, such as screen size and JVM. I don't think this is "presence" in the sense that much of this information is probably not useful to watchers. However, it does represent valid device information and could conceivably appear there. We do have a specification, RFC 3840, which allows a client to declare its capabilities to the server. That specification does not dictate how this information is used. One usage is caller preferences, RFC 3841, which allows for capability-based called routing. However, I think Helsen has in mind a usage where the provider/domain owner simply wants to look at this profile data for some reason, and that is certainly possible. We have only a very limited set of capabilities declare right now, a much, much, much smaller subset of what is in UAProf. -Jonathan R. Paul Kyzivat wrote: > Helsen, > > I don't understand your terminology very well, or what you are trying to > achieve. > > By 'client' I guess you mean a device addressed by a contact in a tuple > of the presence document, rather than a subscriber to presence. Is that > right? > > I don't know precisely what role you have in mind for 'operator'. Is it > the operator of the presence server itself? Or is it something that is a > client of the PS. What is it doing that requires it to know this > information? > > In general the device will probably be publishing its own presence > status to the presence server. If so the extension you suggest would > simply cause it to push this invariant information over and over. > > This kind of info can already be polled using OPTIONS. Why isn't that > enough? > > Paul > > Helsen Frank wrote: > >> Hello, >> >> >> At this moment, draft-ietf-simple-prescaps-ext-01 does not provide a >> way to indicate to the server which client the user uses. I can >> imagine that an operator has specific client capabilities he would >> like to know (e.g. java virtual machine version, screen size). When >> including this client information, the server could retrieve the >> client capabilities from his e.g. his DB. With this extension, the >> operator has control over the client information and is not dependend >> on the information the client provides to him. >> Next example shows a possible extension >> >> >> Siemens >> CX65 >> 2.103564 >> >> >> Regards, >> >> Frank >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 12:22:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21695; Fri, 24 Sep 2004 12:22:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsws-0004oD-3K; Fri, 24 Sep 2004 12:29:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAshN-00057x-HZ; Fri, 24 Sep 2004 12:13:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsT0-00028S-5A for simple@megatron.ietf.org; Fri, 24 Sep 2004 11:58:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20265 for ; Fri, 24 Sep 2004 11:58:35 -0400 (EDT) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsa1-0004MK-6c for simple@ietf.org; Fri, 24 Sep 2004 12:05:53 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8OFulT00706; Fri, 24 Sep 2004 18:56:47 +0300 (EET DST) X-Scanned: Fri, 24 Sep 2004 18:56:36 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i8OFuaBP006898; Fri, 24 Sep 2004 18:56:36 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00tabj2e; Fri, 24 Sep 2004 18:56:34 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8OFuXS27887; Fri, 24 Sep 2004 18:56:33 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 24 Sep 2004 18:54:36 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 24 Sep 2004 18:54:35 +0300 Received: ESEBE054.NOE.Nokia.com 172.21.143.44 from 172.21.39.126 172.21.39.126 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost by ESEBE054.NOE.Nokia.com; 24 Sep 2004 18:54:36 +0300 Subject: Re: [Simple] Presence Data Model: Identifying services From: Aki Niemi To: ext Paul Kyzivat In-Reply-To: <41542824.1010000@cisco.com> References: <4152EFED.9030206@cisco.com> <1096029424.6605.18.camel@localhost.localdomain> <41542824.1010000@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1096041275.9809.70.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 24 Sep 2004 18:54:36 +0300 X-OriginalArrivalTime: 24 Sep 2004 15:54:35.0970 (UTC) FILETIME=[CA60B220:01C4A24E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: SIMPLE WG , Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Inline. On Fri, 2004-09-24 at 16:59, ext Paul Kyzivat wrote: > > Hmm... If the scheme is that ambiguous, then perhaps its definition > > needs to improve. > > Why? There is no particular reason why tel: should mean voice. We don't > restrict sip: that way, and http: doesn't say much about what you can do > either. (I can use http to exchange html, vxml, xcap, etc.) There is a big difference. I can safely assume that for sip:, I am able to send a SIP request and the other end will understand it; but probably not an HTTP request, or let's say an SMTP message using that URI. I admit tel is more problematic, since it is more of a name, really without a protocol attached to it, and sending a SIP request to it might actually work (because we've defined what that means). But the inverse isn't true, since POTS phones don't do IM or anything fancy like that. That's why I think it's futile to build support for them on top of tel. BTW, there is also really no way to know whether I can send an SMS to that telephone number (outside of recognizing it as a mobile number). Which is one of the reasons an explicit smsto URI would be nicer... > AFAIK, tel: is an addressing format and namespace. The following is from > draft-ietf-iptel-rfc2806bis-09: > > The "tel" URI telephone number is not restricted in the type of > termination point it refers to. The termination point can be in the > public telephone network, a private telephone network or the > Internet. The termination point can be fixed or wireless and address > a fixed wired, mobile or nomadic terminal. The terminal addressed > can support any electronic communication service (ECS) including > voice, data and fax. Right, but I definitely don't think that IM or voice+IM session are ECSs. SIP happens to have a linkage in that if I INVITE a tel URI with appropriate media (e.g., voice or fax), then it may work if there is an appropriate GW in place or a termination point that speaks SIP. > >>For instance, it may prove convenient to publish a tel URI for a sip > >>endpoint that is capable of both voice and IM. Then calls via the > PSTN > >>will work, calls from a sip audio phone will work, calls from > another > >>voice+im client will have access to voice and IM. > > > > IMO the most obvious solution here is that if the endpoint wants to > > advertize services other than (or in addition to) telephony, it > > publishes a SIP or IM tuple as well as a tel tuple. Is there a > reason > > this would not work? > > I don't see a problem here, and so I don't feel a need for a solution. > > I agree that other address forms are probably desirable in this case, > for a variety of reasons. But that doesn't mean we should > automatically > assume tel: implies voice telephony and only that. I think we have to assume tel implies some telephony, or ECS service (whatever that means). If a presentity wants to advertize services beyond those, then it is only reasonable that those other contacts are also shown in presence. > One place where this situation may well come up is when the tel: uri > is > used as the presentity address. (Something that should be ok, and > makes > sense to use if you are a client and that is all you have.) It may be > that the user doesn't want to expose device addresses, and so provides > only the presentity address back as the contact in the tuple(s). I don't understand what the problem there is. Even if tel URI was allowed as the entity attribute in PIDF (which it isn't AFAIK) then that presence document would simply state the status of telephony services, nothing more. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 12:42:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24204; Fri, 24 Sep 2004 12:42:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAtGh-0005XQ-64; Fri, 24 Sep 2004 12:50:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsr6-0007mB-SG; Fri, 24 Sep 2004 12:23:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAshb-0005ED-Dt for simple@megatron.ietf.org; Fri, 24 Sep 2004 12:13:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21116 for ; Fri, 24 Sep 2004 12:13:41 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsoc-0004dQ-R0 for simple@ietf.org; Fri, 24 Sep 2004 12:20:59 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 24 Sep 2004 12:29:45 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8OGD9bx008952; Fri, 24 Sep 2004 12:13:09 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-208.cisco.com [64.100.229.208]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCG00648; Fri, 24 Sep 2004 09:13:08 -0700 (PDT) Message-Id: <4.3.2.7.2.20040924121100.02f569e8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 Sep 2004 12:13:08 -0400 To: Jonathan Rosenberg , Paul Kyzivat From: Mike Hammer Subject: Re: [Simple] Extend UA Capabiity Extension to PIDF In-Reply-To: <415441AE.4070107@dynamicsoft.com> References: <41542ED2.2090000@cisco.com> <57FD2C3A246F76438CA6FDAD8FE9F1958B57D9@hrtades7.atea.be> <41542ED2.2090000@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e All, It might not be in the best interest of the user to broadcast too much detail about the configuration of the device as this might just let miscreants know what sort of tools to use to attack the device. May save some reconaissance/scanning time on the attacker's part. Mike At 11:47 AM 9/24/2004 -0400, Jonathan Rosenberg wrote: >My guess is that Helsen is looking at something equivalent to the UAProf >functions in WAP, which allow a client to push fairly complicated >information about itself, such as screen size and JVM. I don't think this >is "presence" in the sense that much of this information is probably not >useful to watchers. However, it does represent valid device information >and could conceivably appear there. > >We do have a specification, RFC 3840, which allows a client to declare its >capabilities to the server. That specification does not dictate how this >information is used. One usage is caller preferences, RFC 3841, which >allows for capability-based called routing. However, I think Helsen has in >mind a usage where the provider/domain owner simply wants to look at this >profile data for some reason, and that is certainly possible. > >We have only a very limited set of capabilities declare right now, a much, >much, much smaller subset of what is in UAProf. > >-Jonathan R. > > > >Paul Kyzivat wrote: > >>Helsen, >>I don't understand your terminology very well, or what you are trying to >>achieve. >>By 'client' I guess you mean a device addressed by a contact in a tuple >>of the presence document, rather than a subscriber to presence. Is that right? >>I don't know precisely what role you have in mind for 'operator'. Is it >>the operator of the presence server itself? Or is it something that is a >>client of the PS. What is it doing that requires it to know this information? >>In general the device will probably be publishing its own presence status >>to the presence server. If so the extension you suggest would simply >>cause it to push this invariant information over and over. >>This kind of info can already be polled using OPTIONS. Why isn't that enough? >> Paul >>Helsen Frank wrote: >> >>>Hello, >>> >>> >>>At this moment, draft-ietf-simple-prescaps-ext-01 does not provide a way >>>to indicate to the server which client the user uses. I can imagine >>>that an operator has specific client capabilities he would like to know >>>(e.g. java virtual machine version, screen size). When including this >>>client information, the server could retrieve the client capabilities >>>from his e.g. his DB. With this extension, the operator has control >>>over the client information and is not dependend on the information the >>>client provides to him. >>>Next example shows a possible extension >>> >>> >>> Siemens >>> CX65 >>> 2.103564 >>> >>> >>>Regards, >>> >>>Frank >>> >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 12:46:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24561; Fri, 24 Sep 2004 12:46:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAtJw-0005eC-QA; Fri, 24 Sep 2004 12:53:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsrJ-0007uQ-1j; Fri, 24 Sep 2004 12:23:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAso9-0007CP-HB for simple@megatron.ietf.org; Fri, 24 Sep 2004 12:20:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21600 for ; Fri, 24 Sep 2004 12:20:27 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsvB-0004lS-3Q for simple@ietf.org; Fri, 24 Sep 2004 12:27:45 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 24 Sep 2004 09:25:32 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8OGJgwr017597 for ; Fri, 24 Sep 2004 09:19:49 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALU79396; Fri, 24 Sep 2004 12:19:48 -0400 (EDT) Message-ID: <41544924.30008@cisco.com> Date: Fri, 24 Sep 2004 12:19:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'simple@ietf.org'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Subject: [Simple] Review of draft-ietf-simple-message-sessions-08 - Chunking X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Out approach to chunking has evolved thru the versions, and the document doesn't seem wholely clear and consistent about what we have arrived at. In fact, I am not entirely certain I know fully what we have decided, and I can't figure it out for certain from the document. I would propose specific wording changes, but first I want to get clarification about how we think it should now work. Based on scattered information in the doc, and reading between the lines, and factoring in stuff from conversations along the way, I *think* the following is intended: - only SEND messages are chunkable - there are two kinds of chunks: interrruptible and uninterrupible. - a chunk is uninterruptible if it has a Byte-Range header with a numeric range-end. - other chunks are interruptible. (No Byte-Range, or a Byte-Range with a range-end of "*".) - uninterruptible chunks MUST NOT have a range-end greater than 2048. - chunks other than the last SHOULD (or MUST?) have a body ('data' in the syntax) of length exactly 2048. If SHOULD, what is a valid reason to violate? - responses never have bodies at all. Requests other than SEND may have a body but are unchunkable. The presence of a Byte-Range in a request other than SEND says nothing about the body of that request. (In REPORT it refers to the SEND being reported on. See separate thread on Byte-Range.) This at best seems irregular and weird. Section 6.3.1 says: "it is possible the body is shorter than the range-end field indicates. This can occur if the sender interrupted a SEND request unexpectedly." Based on what I have interpretted above, this is no longer possible. (To be interrupted it must have had a range-end of "*".) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 12:46:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24674; Fri, 24 Sep 2004 12:46:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAtKq-0005gd-JH; Fri, 24 Sep 2004 12:54:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAssD-000813-0A; Fri, 24 Sep 2004 12:24:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAso9-0007CW-Tt for simple@megatron.ietf.org; Fri, 24 Sep 2004 12:20:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21603 for ; Fri, 24 Sep 2004 12:20:27 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsuy-0004l6-AC for simple@ietf.org; Fri, 24 Sep 2004 12:27:45 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 24 Sep 2004 09:25:19 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8OGJawp017505 for ; Fri, 24 Sep 2004 09:19:36 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALU79388; Fri, 24 Sep 2004 12:19:42 -0400 (EDT) Message-ID: <4154491E.5050806@cisco.com> Date: Fri, 24 Sep 2004 12:19:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Subject: [Simple] Review of draft-ietf-simple-message-sessions-08 - nits X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit I just did a fairly careful review of draft-ietf-simple-message-sessions-08. I came up with a bunch of comments. I will include the nits here, but in the interest of discussion I will break the rest up into a number of separate threads. Paul Section 3, near the end: "This document specifies MSRP behavior only peer-to-peer session...". Is awkward wording. Suggest inserting "for a" in front of "peer-to-peer". Section 4.3, last paragraph: "... but some other systems choose to use a value of "partial" to reduce the load on the servers caused by 200 OK responses, but still allow error responses to be sent in many cases." This will make sense later, but it doesn't make sense at this point in the document because the linkage between the report and the 200 hasn't been made. Suggest something like: "... but some other systems choose to use a value of "partial" to reduce the load on the servers. As will be seen in section 6.2, this will omit 200 OK responses and the load they cause, but still allow error responses to be sent in many cases." Section 4.4, 4th paragraph from end, there is a sentence fragment that should be combined with the next sentence: "If the receiving endpoint receives more than one message with the same Message-ID. It SHOULD assume that the messages are duplicates." Should be: "If the receiving endpoint receives more than one message with the same Message-ID it SHOULD assume that the messages are duplicates." The word "insure" is used twice in this document, and in both cases is should be "ensure". Section 6.1.2 says: "An MSRP endpoint MUST be able to generate success REPORT requests." But nowhere do I find a comparable statement about failure reports. I think the endpoint MUST be able to do both. Section 6.1.3, 1st paragraph: there is an instance of "respons" that should be "response". Section 6.3.1: s/If chunks data/If chunk data/ Section 7.1 says to use "*" to indicate willingness to accept any content type. This has always seemed gratuitous to me, since the mime syntax for types already allows "*/*" to mean that. I think it would minimize future issues if we just accepted that instead of specifying "*" as a special case. This would require a small change to the syntax of 'type' and 'subtype'. Section 7.1 uses both "container types" and "compound types" to mean the same thing. Can we just pick one and stick with it? (I don't care which one.) Section 7.1.5 says: "Instead, MSRP now specifies a default connection direction." Its not a default, since you can't change it. I think what is meant is: "MSRP now associates connection direction with the direction the offer travels." Section 10.5: Shows using a REGISTER to query for the contacts. There really isn't anything wrong here, but it may cause some readers to conclude that using REGISTER this way is something that should normally be done. Might be worth a disclaimer that this is only shown for purposes of clarifying the example. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 12:47:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24724; Fri, 24 Sep 2004 12:47:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAtLN-0005hS-Kd; Fri, 24 Sep 2004 12:54:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsyx-0000pk-Of; Fri, 24 Sep 2004 12:31:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsov-0007F2-4v for simple@megatron.ietf.org; Fri, 24 Sep 2004 12:21:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21635 for ; Fri, 24 Sep 2004 12:21:14 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsvv-0004mV-PD for simple@ietf.org; Fri, 24 Sep 2004 12:28:33 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2004 09:33:18 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8OGKZwp018292 for ; Fri, 24 Sep 2004 09:20:36 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALU79486; Fri, 24 Sep 2004 12:20:40 -0400 (EDT) Message-ID: <41544958.1040009@cisco.com> Date: Fri, 24 Sep 2004 12:20:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'simple@ietf.org'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Simple] Review of draft-ietf-simple-message-sessions-08 - Overlapping Chunks X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Section 6.3.1 discusses how to handle the receipt of overlapping chunks, specifying that the last received copy of any particular byte wins. I don't think this is good. If the overlapping chunks contain consistent data then it doesn't matter which takes precedence. If they contain conflicting data then reordering of chunks can affect the result unpredictably. This rule also prevents the recipient from rendering a byte when it and all preceding bytes have been received. I think it should be permissible for the recipient to check for inconsistency in the overlapping case, and report an error if so. We may want to require this checking. (Since it typically won't happen it shouldn't have a performance impact.) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 12:48:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24804; Fri, 24 Sep 2004 12:48:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAtM2-0005is-V9; Fri, 24 Sep 2004 12:55:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsz2-0000q6-AH; Fri, 24 Sep 2004 12:31:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsox-0007G8-2i for simple@megatron.ietf.org; Fri, 24 Sep 2004 12:21:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21640 for ; Fri, 24 Sep 2004 12:21:16 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsvx-0004mV-Eb for simple@ietf.org; Fri, 24 Sep 2004 12:28:34 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2004 09:33:28 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8OGKkSI011210 for ; Fri, 24 Sep 2004 09:20:46 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALU79515; Fri, 24 Sep 2004 12:20:50 -0400 (EDT) Message-ID: <41544962.2080509@cisco.com> Date: Fri, 24 Sep 2004 12:20:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: [Simple] Review of draft-ietf-simple-message-sessions-08 - Byte Ranges in REPORTs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit I am really confused about how byte ranges are supposed to work in reports, and I suspect we are permitting a bunch of nonsense. Fundamentally, a message can only be considered a success if all its bytes are received successfully. If it is to be positively acknowledged with success reports, then there must be success reports covering every byte. Is there any point in sending a success report for less than the entire message? It doesn't help the receiver, and actually makes more work because it then requires keeping track of what bytes have been confirmed. And it doesn't ease the job of the sender, who could easily just wait until all has been received before sending the success report. The flip side is that a message fails if a single byte fails. At that point it does no good to know that other parts succeeded or failed. So while it makes sense to send a failure report based on problems with a single chunk, there is little value in saying which byte range failed. Bottom line: unless I have missed something, there is no reason for Byte-Range in REPORT or responses. A success report should only be sent after all the chunks of a message have been received. A failure report, or an error status, can be sent at the time the failure of a single chunk is known, but need not identify the byte range. (In that case, maybe the Byte-Range could be optional for debugging purposes only.) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 12:48:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24881; Fri, 24 Sep 2004 12:48:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAtMI-0005jX-FP; Fri, 24 Sep 2004 12:55:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsz3-0000qV-QB; Fri, 24 Sep 2004 12:31:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsox-0007Ge-He for simple@megatron.ietf.org; Fri, 24 Sep 2004 12:21:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21643 for ; Fri, 24 Sep 2004 12:21:17 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsvz-0004mV-4j for simple@ietf.org; Fri, 24 Sep 2004 12:28:35 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2004 09:33:35 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8OGKqwp018599 for ; Fri, 24 Sep 2004 09:20:52 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALU79526; Fri, 24 Sep 2004 12:20:58 -0400 (EDT) Message-ID: <4154496A.40502@cisco.com> Date: Fri, 24 Sep 2004 12:20:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Simple] Review of draft-ietf-simple-message-sessions-08 - Port in m-line X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Section 7.1 says: "An offered or accepted MSRP media-line MUST have the following value exactly ... m=message 9 msrp *" We've been thru this before. It can't always be 9 because there could be two media sections and they can't both use 9. I think we say it must be: m=message msrp * and then say SHOULD be 9, but MAY be something else if 9 has already been used. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 12:48:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24924; Fri, 24 Sep 2004 12:48:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAtMe-0005kI-Bk; Fri, 24 Sep 2004 12:56:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsz4-0000qe-91; Fri, 24 Sep 2004 12:31:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsoy-0007H0-3q for simple@megatron.ietf.org; Fri, 24 Sep 2004 12:21:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21646 for ; Fri, 24 Sep 2004 12:21:17 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsvz-0004mV-Mi for simple@ietf.org; Fri, 24 Sep 2004 12:28:36 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2004 09:33:41 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8OGKwwp018689 for ; Fri, 24 Sep 2004 09:20:58 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALU79530; Fri, 24 Sep 2004 12:21:03 -0400 (EDT) Message-ID: <4154496F.2010405@cisco.com> Date: Fri, 24 Sep 2004 12:21:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Subject: [Simple] Review of draft-ietf-simple-message-sessions-08 - Syntax X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Section 5: MSRP URL syntax: There is an undefined reference to "ALPHANUM". RFC2396 defines "alphanum", but that is only a single byte. Suggest replacing ALPHANUM with 1*alphanum, and reference 2396 for alphanum. Rohan wanted "?" syntax added. Section 8: Formal Syntax: I don't know what resulted in the following: dUmMy= "Status:" SP namespace SP short-status [SP text-reason] It must have been intentional. But the 'Status' element is undefined, so I think this needs to be changed to: Status = "Status:" SP namespace SP short-status [SP text-reason] We define pval as: pval = token / quoted-string We might want to consider making it compatible with generic-param in 3261, which also permits it to be a 'host'. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 12:49:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24968; Fri, 24 Sep 2004 12:49:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAtMs-0005l5-Kc; Fri, 24 Sep 2004 12:56:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAszq-00015V-Qk; Fri, 24 Sep 2004 12:32:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsoy-0007HT-Rt for simple@megatron.ietf.org; Fri, 24 Sep 2004 12:21:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21650 for ; Fri, 24 Sep 2004 12:21:18 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsw0-0004mV-9O for simple@ietf.org; Fri, 24 Sep 2004 12:28:36 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2004 09:33:44 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8OGL2SI011526 for ; Fri, 24 Sep 2004 09:21:03 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALU79535; Fri, 24 Sep 2004 12:21:06 -0400 (EDT) Message-ID: <41544972.7070503@cisco.com> Date: Fri, 24 Sep 2004 12:21:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [Simple] Review of draft-ietf-simple-message-sessions-08 - max-size X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Section 7.1 says: "An endpoint MAY indicate the maximim size message they wish to receive using the max-size a-line attribute". Does this apply only to a *message* - namely the content of a SEND request? Or does this apply to any and all requests (including future extensions) that have content? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 12:49:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25052; Fri, 24 Sep 2004 12:49:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAtNN-0005ma-PS; Fri, 24 Sep 2004 12:56:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAt3N-0001Xw-DS; Fri, 24 Sep 2004 12:36:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAsp0-0007Ht-62 for simple@megatron.ietf.org; Fri, 24 Sep 2004 12:21:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21655 for ; Fri, 24 Sep 2004 12:21:19 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAsw0-0004mV-Qh for simple@ietf.org; Fri, 24 Sep 2004 12:28:38 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2004 09:33:51 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8OGL7wp018873 for ; Fri, 24 Sep 2004 09:21:08 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALU79550; Fri, 24 Sep 2004 12:21:12 -0400 (EDT) Message-ID: <41544978.3020408@cisco.com> Date: Fri, 24 Sep 2004 12:21:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Simple] Review of draft-ietf-simple-message-sessions-08 - Misc X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Don't forget to add 405 for reporting a method that isn't understood. Example Bugs: Section 10.1, step 4: CRLF missing before the "Hi" Section 10.1, steps 5 & 7: To-Path and From-Path values are backward. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 13:22:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28510; Fri, 24 Sep 2004 13:22:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAtsx-0006tt-7Z; Fri, 24 Sep 2004 13:29:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAtGB-0005zr-Uc; Fri, 24 Sep 2004 12:49:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAt0X-00017o-1Q for simple@megatron.ietf.org; Fri, 24 Sep 2004 12:33:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22975 for ; Fri, 24 Sep 2004 12:33:14 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAt7X-0005AI-JV for simple@ietf.org; Fri, 24 Sep 2004 12:40:33 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 24 Sep 2004 12:49:18 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8OGWgbx012901; Fri, 24 Sep 2004 12:32:42 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-208.cisco.com [64.100.229.208]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCG02165; Fri, 24 Sep 2004 09:32:41 -0700 (PDT) Message-Id: <4.3.2.7.2.20040924122304.00b27540@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 Sep 2004 12:32:41 -0400 To: Jonathan Rosenberg , Paul Kyzivat From: Mike Hammer Subject: Re: meaning of tel URI in presence data model, was: Re: [Simple] Presence Data Model: Identifying services In-Reply-To: <41543F2A.9070708@dynamicsoft.com> References: <41542824.1010000@cisco.com> <4152EFED.9030206@cisco.com> <1096029424.6605.18.camel@localhost.localdomain> <41542824.1010000@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: SIMPLE WG , Aki Niemi , Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e At 11:37 AM 9/24/2004 -0400, Jonathan Rosenberg wrote: >inline. > >Paul Kyzivat wrote: > >> >>Aki Niemi wrote: >> >>>On Thu, 2004-09-23 at 18:46, ext Paul Kyzivat wrote: >>> >>>>I don't find the scheme as clearcut as that. I don't think one should >>>>assume "tel" indicates telephony. It perhaps does imply reachability >>>>via various telephony protocols for purpose of voice communications, >>>>but is not exclusive to that. If the tel: URI can be mapped to a sip >>>>endpoint and protocol, then non-voice, non-telephony capabilities are >>>>not excluded. >>> >>> >>>Hmm... If the scheme is that ambiguous, then perhaps its definition >>>needs to improve. >> >>Why? There is no particular reason why tel: should mean voice. We don't >>restrict sip: that way, and http: doesn't say much about what you can do >>either. (I can use http to exchange html, vxml, xcap, etc.) >>AFAIK, tel: is an addressing format and namespace. The following is >>from draft-ietf-iptel-rfc2806bis-09: >> The "tel" URI telephone number is not restricted in the type of >> termination point it refers to. The termination point can be in the >> public telephone network, a private telephone network or the >> Internet. The termination point can be fixed or wireless and address >> a fixed wired, mobile or nomadic terminal. The terminal addressed >> can support any electronic communication service (ECS) including >> voice, data and fax. > >Sigh... here is another case where the tel URI's confusion about what it >really is, is getting us into trouble. > >If you think about the tel URI as a urn scheme, whereby resolution to an >actual set of communication resources is done using a resolution service >(ala DDDS), then it becomes fairly obvious (to me at least) that you would >simply never even put that URN into the of a presence document, >since it doesnt represent a communications service at all. If anything, >it's closer to a presentity identifier. Rather, you would put the >individual service URIs that result from the DDDS lookups. > >However, the tel URI is somewhat schizophrenic. Its not a URN, even though >it can use (but doesnt require) URN-like resolution services such as enum. >It's like a URN in that it can refer to an abstract name and be resolved >to a wealth of different URIs of many different schemes and services. Its >unlike a URN in that it is also used to refer to telephone resources, and >the implication of the tel URI is that "I can dial this from a PSTN phone >or enterprise phone and reach something". In that aspect, its more like a >protocol URI. > >What does this mean for presence? To be honest, in the discussion in the >data model draft, I have assumed the protocol URI meaning. That is, it >refers to a PSTN (or private network) circuit endpoint, period. That, of >course, is a BIG assumption, and something we should discuss. I would >propose that we keep this assumption and merely state it. In such a case, >it would not make sense for the recipient of a presence document to look >up such a tel URI in enum. Rather, it knows its a telephony resource >right away and can "dial it". > >Comments? There was some discussion on one of the mail lists that a parameter was needed to indicate that an ENUM dip had already been performed and determined that this particular terminal must be reached by going to the PSTN, i.e., that it was a circuit endpoint. That could be one of the things that the presence document indicates. If one were to do an ENUM lookup and receive a list of indications of IP endpoints, well, I would have expected that list to have been included in the presence for that user in the first place. I think it much more useful for ENUM to point to a presence address leading to richer data with corresponding user controls than the reverse. So, I guess I'm in agreement with Jonathan. Mike >-Jonathan R. > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 15:28:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08241; Fri, 24 Sep 2004 15:28:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAvrT-0000y0-6q; Fri, 24 Sep 2004 15:36:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAvTl-0001Pr-2t; Fri, 24 Sep 2004 15:11:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAvQW-0007U9-TK for simple@megatron.ietf.org; Fri, 24 Sep 2004 15:08:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06613 for ; Fri, 24 Sep 2004 15:08:15 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAvXY-0000ex-Gs for simple@ietf.org; Fri, 24 Sep 2004 15:15:34 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 24 Sep 2004 12:08:03 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i8OJ7d9O004867; Fri, 24 Sep 2004 12:07:40 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALU96482; Fri, 24 Sep 2004 15:07:38 -0400 (EDT) Message-ID: <4154707A.7060102@cisco.com> Date: Fri, 24 Sep 2004 15:07:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Goeman Stefan Subject: Re: [Simple] Presence Data Model: Identifying services References: <57FD2C3A246F76438CA6FDAD8FE9F1956921A9@hrtades7.atea.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f31e050dc7ce62aeed70903f7da21012 Content-Transfer-Encoding: 7bit Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a5514bacad4d93d5535dfe9fdc83bbb7 Content-Transfer-Encoding: 7bit Goeman Stefan wrote: > Hello, > > Comments inline. > > Greetings, > Stefan. > > >>>On second thought, I realized that there is one problem: >>>How will this work together with the Authorization rules. >> >>I think you are imagining a problem here. I don't think it makes much >>sense for the client to determine authorization, beyond simply being >>authorized to subscribe to presence. If the PS gives you the >>info, just >>display it. The PS can filter out what it thinks you should >>not see or do. >> > > I think we are talking about different things here. I was taking about me as > presentity managing and editing my own authorization rules. Since my > presence information is also "my property" I would expect that I would be > able to play the role of a rule maker. Clearly, you have to edit your rules > somehow, via some device. Oh, sorry. Yes, the presentity does have to manage rules for what will be provided to subscribers. There is already much work on that. Paul >>In any case there is no good way for a client to determine if it is >>permitted to do something, short of trying to do it. >> >> Paul >> >> > Here, again, you >> >>>have to present the authorization rules in a meaningful >> >>manner (via some >> >>>front end user interface). If I am correct, the idea is to >> >>retrieve the >> >>>authorization rules via XCAP from the policy server, make >> >>some changes and >> >>>provide the changes back to the policy server via XCAP. >> >>Yet, the policy >> >>>server is not aware of any services like IM, voice call, >> >>... . So, again, >> >>>the device should make this mapping. This works well if you >> >>only use one >> >>>device. But, if you use more than one device, with >> >>different capabilities >> >>>and services, it does not work anymore. A device can't say something >>>meaningful over a service it does not support. >> >>Consequently, you can not >> >>>edit every aspect of the authorization rules on your >> >>device. I think this is >> >>>problematic, and I don't see a good solution right know. >>> >>>Greetings, >>>Stefan. >>> >>> >>> >>>>-----Original Message----- >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>Sent: donderdag 23 september 2004 17:47 >>>>To: Markus.Isomaki@nokia.com >>>>Cc: Goeman Stefan; simple@ietf.org >>>>Subject: Re: [Simple] Presence Data Model: Identifying services >>>> >>>> >>>>I have comments both to Markus' original posting and to the ensuing >>>>discussion. So I will just insert inline in the latest >>>>response I have. >>>> >>>> Paul >>>> >>>>Markus.Isomaki@nokia.com wrote: >>>> >>>> >>>>>Hi Stefan, >>>>> >>>>>Comments back to you inline. >>>>> >>>>>(Yes, I absolutely agree with you on the usefulness of the >>>> >>>>Presence Data Model draft and that it should have been the >>>>starting point, at least right after PIDF.) >>>> >>>> >>>>>>-----Original Message----- >>>>>>From: simple-bounces@ietf.org >>>>>>[mailto:simple-bounces@ietf.org]On Behalf >>>>>>Of ext Goeman Stefan >>>>>>Sent: 23 September, 2004 14:42 >>>>>>To: 'simple@ietf.org' >>>>>>Subject: RE: [Simple] Presence Data Model: Identifying services >>>>>> >>>>>> >>>>>>Hello, >>>>>> >>>>>>Comments inline >>>>>> >>>>>>P.S.: In general, I find the Presence Data model draft a good >>>>>>document. This >>>>>>is how things should have started in the first place. >>>>>> >>>>>>Greetings, >>>>>>Stefan. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: simple-bounces@ietf.org >>>>>>>[mailto:simple-bounces@ietf.org] On Behalf Of >>>>>> >>>>>>Markus.Isomaki@nokia.com >>>>>> >>>>>> >>>>>> >>>>>>>Sent: donderdag 23 september 2004 10:10 >>>>>>>To: simple@ietf.org >>>>>>>Subject: [Simple] Presence Data Model: Identifying services >>>>>>> >>>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I have a comment on Presence Data Model draft about the >>>>>>>identification/characterization of services. (I know this has >>>>>>>been discussed for a while already, but I still think the >>>>>>>current way is somewhat unadequate.) >>>>>>> >>>>>>>The current Data Model draft says: >>>>>>> >>>>>>> In this model, services are not explicitly enumerated. >>>>>> >> That is, >> >>>>>>> there is no "service" attribute with values of "ptt" or >>>>>>>"telephony". >>>>>>> Rather, the service is identified in one of two ways. In >>>>>>>many cases, >>>>>>> the URI scheme is a clear indicator of service. An "sms" >>>>>>>URI clearly >>>>>>> indicates SMS, and a "tel" URI clearly indicates >>>>>>>telephony. >>>>>> >>>>I don't find the scheme as clearcut as that. I don't think >>> >>one should >> >>>>assume "tel" indicates telephony. It perhaps does imply >>>>reachability via >>>>various telephony protocols for purpose of voice >>>>communications, but is >>>>not exclusive to that. If the tel: URI can be mapped to a sip >>>>endpoint >>>>and protocol, then non-voice, non-telephony capabilities are >>>>not excluded. >>>> >>>>For instance, it may prove convenient to publish a tel URI >>> >>for a sip >> >>>>endpoint that is capable of both voice and IM. Then calls via >>>>the PSTN >>>>will work, calls from a sip audio phone will work, calls >>> >>from another >> >>>>voice+im client will have access to voice and IM. >>>> >>>> >>>>>>>For some >>>>>> >>>>>>> URIs, there may be many services available, for example, >>>>>> >>>>>>SIP. For >>>>>> >>>>>> >>>>>> >>>>>>> those services, each service has a set of >>>>>> >>>>>>characteristics, each of >>>>>> >>>>>> >>>>>> >>>>>>> which has a well-defined meaning, such that a system can >>>>>>> unequivocally determine whether or not the service has that >>>>>>> characteristic. This is discussed in more detail in [5]. >>>>>>> >>>>>>>I agree that the contact URI scheme is the most important >>>>>>>piece of information to distinguish what is the "service". >>>>>>>(There are some gaps here too, since e.g. the URI schemes for >>>>>>>SMS or MMS do not even exist, and there may be other non-IETF >>>>>>>protocols that face the same problem.) However, I'm not >>>>>>>convinced that listing the signaling/media characteristics of >>>>>>>the end-point or service really gives enough information to >>>>>>>the watcher to really determine if it can communicate with >>>>>>>the advertised service/application. >>>>>>> >>>>>>>The refenced draft [5] has a following example: >>>>>>> >>>>>>>5.6 Walkie-talkie >>>>>>> >>>>>>> The walkie-talkie service allows real-time voice communication >>>>>>> between participants. Only one participant can speak at a >>>>>>>time; that >>>>>>> is, communication is half-duplex. Typically, >>>>>> >>>>>>participants press a >>>>>> >>>>>> >>>>>> >>>>>>> button to indicate that they are ready to speak, although other >>>>>>> mechanism (e.g. voice activation) are occasionally used. >>>>>>> >>>>>>> Support for the Walkie-Talkie service can be deduced by >>>>>>>observing the >>>>>>> presence of a contact URI with a scheme of "sip:", >>>>>> >>>>>>associated with >>>>>> >>>>>> >>>>>> >>>>>>> the following minimal set of capabilities: >>>>>>> half INVITE,ACK,BYE,CANCEL >>>>>>> >>>>>>>Presumably this is the same as the service sometimes called >>>>>>>Push-to-Talk (PTT, PoC). The concrete problem is that there >>>>>>>are several _non-interworking_ variants of this service, that >>>>>>>still all would match the characteristics listed above, as >>>>>>>the _SIP_ part might still be standard, at least for some >>>>>>>methods etc. But still the communication would fail even if >>>>>>>the tuple looks OK. >>>>>> >>>>>>I don't think I understand you here. I would expect that if >>>>>>both end-point >>>>>>SIP US support exactly the same methods, the SIP UA should >>>>>>also be able to >>>>>>handle those SIP method. Or, to phase it in another way, both >>>>>>end-point >>>>>>should be able to communicate with each other only based on >>>>>>using these >>>>>>capabilities. >>>>>> >>>>> >>>>> >>>>>To some extent that might be possible, but there might be >>>> >>>>differences e.g. in floor control etc., which make the >>>>service still practically unusable, which means that the >>>>presence document shouldn't give the impression that the >>>>communication will work. Obviously it is possible to list all >>>>those additional characteristics as well (and this might be a >>>>good idea too), but for instance if presence of a network >>>>game is published, it is easier to _explicitely_ tell what >>>>the game is by providing some sort of unique id which would >>>>be only meaningful to those similar game clients. >>>> >>>>>>>(Also if I saw the characteristics above, >>>>>>>I could as well determine that they describe normal VoIP >>>>>>>application running in (very) some old PC with half-duplex >>>>>>>audio drivers, so I claim the service description is hard to >>>>>>>make unambiguous in the first place.) >>>>>> >>>>I think the goal should be that all of these are at least minimally >>>>interoperable. I ought to be able to call a PTT contact from >>>>a regular >>>>voice phone and have *something* reasonable happen. (Maybe >>> >>it is just >> >>>>oneway voice, with the non-ptt caller never getting the >>>>floor, but that >>>>may be better than nothing. >>>> >>>>I think the real problem in this case is not with the capability >>>>approach. It is that the 'duplex' capability is >>>>underspecified. There is >>>>no explanation of how a pair of half duplex endpoints (or one >>>>half-duplex and one full-duplex endpoint) agree on who can talk. >>>> >>>>In the case of the 'voice' capability, it is understood that >>>>having both >>>>endpoints support voice isn't enough to support >>>>communication. There is >>>>an SDP negotiation of codecs, etc. that either succeeds or >>>>fails. There >>>>should be something similar for half-duplex. >>>> >>>> >>>> >>>>>>I also have the impression that it will be difficult to >>>>> >>>>determine the >>>> >>>> >>>>>>services merely based on the SIP methods (and ...) supported >>>>>>by the SIP UA. >>>>>>It possibly might mean that the SIP-based ptt-service on my >>>>>>mobile phone >>>>>>might be mapped onto some communication service on your PC. >>>>>>Then, I wonder >>>>>>who will be responsible for such kind of mapping? Only the >>>>>>end terminals, or >>>>>>is support from the network, presence server, necessary? And, >>>>>>how will one >>>>>>service in one domain be mapped into a service in another >>>>>>domain? I believe >>>>>>there are some open issues here. >>>>> >>>>The intent is that capabilities have common meanings in all >>>>domains, so >>>>they don't need to be mapped. I don't see why there should be any >>>>binding between services and domains. >>>> >>>>In the general case one should assume that there are devices >>>>of widely >>>>varying capabilities in every domain, and that they know best >>>>what they >>>>are capable of. So the device should be the one deciding if >>> >>a contact >> >>>>with and advertised set of capabilties is something it wants >>>>to attempt >>>>communication with. >>>> >>>>In some environment where there is an intermediary in front >>>>of a device >>>>that understands the device and acts on its behalf, then I >>> >>suppose it >> >>>>could make these decisions. But I would consider that the odd case. >>>> >>>> >>>> >>>>>I think that it is fully OK to describe some rather simple >>>> >>>>things using characteristics, but in many cases applications >>>>are more complex. >>>> >>>>Clearly we have chosen not to describe capabilities if full detail. >>>>(E.g. we don't publish codec support.) Because of this, >>> >>there is the >> >>>>possibility that we make a wrong decision about ability to >>>>communicate >>>>and it doesn't get discovered until we try. >>>> >>>>This is ok when the expected probability of failure is low. (We >>>>generally expect that there will be some codec in common, >>> >>or that one >> >>>>end or the other will be able to introduce a transcoder.) >>>> >>>> >>>> >>>>>>>I think the main point of a service tuple is to give the >>>>>>>watcher enough information to know whether he can really >>>>>>>communicate & interoperate with the advertised service. Given >>>>>>>that many services taht are using SIP also have propritary or >>>>>>>non-SIP features, I don't think the current approach is enough. >>>>>> >>>>In cases where the existing capabilities aren't sufficient to >>>>ensure a >>>>good probability of communication, then we should indeed >>>>consider adding >>>>additional capabilities. >>>> >>>>But I continue to object to the notion of "service" as the >>> >>way to do >> >>>>that, because it conveys no semantics about what the >>>>capability is that >>>>it describes. >>>> >>>> >>>> >>>>>>Do you have an example of a service that uses SIP and also has non >>>>>>SIP-features? If your service also uses non-SIP features, >>>>> >>>>you can not >>>> >>>> >>>>>>determine the type of service by only looking at the SIP >>>>> >>>>capabilities >>>> >>>> >>>>>>supported by the SIP UA. Some indication of that non-SIP >>>>>>feature should also >>>>>>be present in the presence document. >>>>>> >>>>> >>>>> >>>>>True, and since some of those non-SIP features might not be >>>> >>>>based on (IETF) standards, it might be good to have the >>>>possibility for the developers of such applications to have a >>>>short cut of saying what the app really is, rather than >>>>having to list characteristics. In the end, some applications >>>>are really not even meant to work with any other than the >>>>exactly same application, for instance some networking games. >>>> >>>>If the intent is to define a closed world, where >>>>interoperability is not >>>>even considered a desirable feature, then I agree. I think that may >>>>indeed be the case for proprietary games. >>>> >>>>But for something like PTT, while it might be in the best >>> >>interest of >> >>>>the maker of a particular PTT solution to keep it closed, I >>>>don't think >>>>it is in the best interest of society or the IETF that this >>>>happen. This >>>>is precisely the forum in which we try to prevent that from >>> >>happening. >> >>>> >>>>>>>Of course each of these proprietary services are allowed to >>>>>>>define additional status or tuple-level extensions to PIDF. >>>>>> >>>>>>Yes, you can always extend the PIDF. My comment here is that >>>>>>this might lead >>>>>>to an "explosion" of applications or services. It will >>>>>>certainly not help >>>>>>interoperability. >>>>> >>>>My point precisely. >>>> >>>> >>>> >>>>>And who would standardize such characteristic definitions. >>>> >>>>It has already taken a couple of years to standardize even >>>>"prescaps", which is just a starting point. >>>> >>>> >>>>>>>However, I would like to have some kind of "service >>>>>>>identifier" as part of the basic framework so that this could >>>>>>>be done in a consistent manner. I think it would help >>>>>>>especially in making of authorization and composition rules >>>>>>>more simple. The current "class" attribute is way too >>>>>> >>>>>>loosely defined. >>>>>> >>>>>> >>>>>> >>>>>>>So the concrete proposal is to include in RPID a "service id" >>>>>>>element that would have a vendor-specific namespace, similar >>>>>>>to e.g. vendor-specific XCAP AUIDs. So for instance the >>>>>>>SIP-based PTT app from vendor xyz.com would have, e.g. >>>>>>>com.xyz.ptt >>>>>>>while the PTT app compliant with OMA would have, e.g. >>>>>>>com.openmobilealliance.ptt >>>>>> >>>>I am not fond of this solution. Done this way, we have defined an >>>>element that has no semantics at all, only syntax. >>>> >>>>I would rather see vendor specific extensions to PIDF. At >>>>least then the >>>>people that support an extension will understand what it means. >>>> >>>>But I would rather see people come forward and do the hard work of >>>>publicly defining new capabilities so that independent >>>>implementations >>>>can use them in an interoperable way. >>>> >>>> >>>> >>>>>>In general, I could agree with that approach. However, I >>>>>>don't see a reason >>>>>>why the vendor specific SIP-based PTT should be different >>>>> >>>>>>from the OMA based >>>>> >>>>> >>>>>>PTT. Simply define one PTT, based on the SIP UA capabilities. >>>>>> >>>>> >>>>> >>>>>Well, for instance Nokia has a prorietary PTT application, >>>> >>>>which uses SIP INVITE etc., so users are essentially >>>>addressed with sip: URI. However, it has some floor control, >>>>media etc. features which make it basically non-interoperable >>>>with clients that are not specifically following that >>>>proprietary spec. >>>> >>>>This is a problem, not a good thing. I realize it has to >>>>happen as part >>>>of the development process, but the goal should be to get out >>>>of it as >>>>fast as possible. >>>> >>>>I would hope that endpoints supporting this would be >>>>described as well >>>>as possible using existing capabilities, and that a >>>>reasonable effort be >>>>made to do something reasonable when some other sip device connects. >>>> >>>>If you really can't deal with a regular voice caller at all, then I >>>>would suggest, as a transitional step, saying that you >>> >>don't support >> >>>>voice, and then advertising some proprietary capability as an >>>>alternative to voice. >>>> >>>> >>>> >>>>>OMA PTT is closer to standard IETF SIP. Unless there is >>>> >>>>some conversion, it does not work with Nokia PTT directly. >>>>There should be some way for distinguishing these two in a >>>>presence document, so that there won't be confusion. I think >>>>the current idea is to do some kind of proprietary PIDF >>>>extensions, but in my opinion a standard XML element in RPID >>>>to tell this kind of information would be better, also for >>>>the purposes of authorization rule making. >>>> >>>>See above for what I think you could do for now. The same >>> >>issues may >> >>>>apply to OMA PTT, and a similar solution could be applied to it. >>>> >>>>Hopefully somebody will come up with a PTT that can be dealt >>>>with more >>>>gracefully. I think that work should be done on better defining >>>>half-duplex, so that it can be used in conjunction with voice to >>>>describe PTT. But it may just turn out to be the wrong thing. >>>>Maybe we >>>>need a "floor-control" capability. >>>> >>>> >>>> >>>>>>>in _addition_ to describing sip:, half-duplex audio, and the >>>>>>>supported methods. Now: >>>>>>>1.) Watcher having one of those apps could see right away >>>>>>>whether it is possible to communicate >>>>>>>2.) Composer getting PUBLISHes from 2 sources could >>>>>>>immediately know that they are from a similar app >>>>>>>3.) The app could set its authorization rules using the >>>>>> >>unique id. >> >>>>>>>The main downside I can see in this approach that if there >>>>>>>are two different proprietary apps that indeed could >>>>>>>communicate at least partially, the watcher might make a >>>>>>>conclusion that communication is not possible baed on >>>>>>>different service-id. >>>>>> >>>>This is my concern as well. >>>> >>>> >>>>>>>However, in this case the watcher still >>>>>> >>>>>>>would have the characteristics visible and could determine >>>>>>>that some interworking could be achieved. >>>>>> >>>>>>Personally, I don't think it is a good idea that an end-user >>>>>>should make >>>>>>such decission. If I get a presence document that indicates >>>>>>that another >>>>>>person is able to receive some type of communication, I >>>>>>expect that that >>>>>>type of communication would actually work when I use it. >>>>> >>>>With high probability. There are no guarantees with presence. For >>>>instance see my mention above of codecs. >>>> >>>> >>>> >>>>>Exactly right. If you are an application who does not >>>> >>>>necessarily aim for interoperability, but still uses sip:, >>>>INVITE etc., you should be able to explicitely say so. >>>> >>>>And you can, without a special notion of service. >>>> >>>> >>>> >>>>>>>For this kind of >>>>>>>reasons there should be careful text about when to use >>>>>>>service-id in the first place, and what can be >>>>>> >>determined from it. >> >>>>>>>Does someone think that this is an absolutely bad idea? If >>>>>>>so, how would you envision solving the issues discussed above? >>>>>> >>>>I still don't buy this. >>>> >>>> >>>> >>>>>>I think more care should be taken in mapping SIP UA >>>>>>capabilities into actual >>>>>>services. That is not so clear to me! >>>>> >>>>>The idea is nice, but I don't see a problem in _addition_ >>>> >>>>defining the application with something like >>>>"com.openmobilealliance.ptt" or "com.nokia.ptt", if that kind >>>>of profile would have more meaning than the list of characteristics. >>>> >>>>I am still opposed to defining an attribute with no semantics. >>>>We have been around this so many times that I am quite >>>>certain that it >>>>will never be possible to get a useful agreement on what >>>>"service" means. >>>> >>>>If it is introduced, I expect it to have problems like those >>>>of the INFO >>>>method. (The arguments for introducing it seem similar.) >>>> >>>> Paul >>>> >>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 15:40:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09085; Fri, 24 Sep 2004 15:40:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAw2z-0001AP-J3; Fri, 24 Sep 2004 15:48:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAvox-0001yg-7c; Fri, 24 Sep 2004 15:33:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAvj7-0007bi-Fz for simple@megatron.ietf.org; Fri, 24 Sep 2004 15:27:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08211 for ; Fri, 24 Sep 2004 15:27:28 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAvq9-0000wn-VI for simple@ietf.org; Fri, 24 Sep 2004 15:34:47 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2004 12:39:33 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8OJQmwp021404; Fri, 24 Sep 2004 12:26:48 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALU98405; Fri, 24 Sep 2004 15:26:52 -0400 (EDT) Message-ID: <415474FC.6090809@cisco.com> Date: Fri, 24 Sep 2004 15:26:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: meaning of tel URI in presence data model, was: Re: [Simple] Presence Data Model: Identifying services References: <4152EFED.9030206@cisco.com> <1096029424.6605.18.camel@localhost.localdomain> <41542824.1010000@cisco.com> <41543F2A.9070708@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: Markus.Isomaki@nokia.com, Aki Niemi , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > >> Why? There is no particular reason why tel: should mean voice. We >> don't restrict sip: that way, and http: doesn't say much about what >> you can do either. (I can use http to exchange html, vxml, xcap, etc.) >> >> AFAIK, tel: is an addressing format and namespace. The following is >> from draft-ietf-iptel-rfc2806bis-09: >> >> The "tel" URI telephone number is not restricted in the type of >> termination point it refers to. The termination point can be in the >> public telephone network, a private telephone network or the >> Internet. The termination point can be fixed or wireless and address >> a fixed wired, mobile or nomadic terminal. The terminal addressed >> can support any electronic communication service (ECS) including >> voice, data and fax. > > > Sigh... here is another case where the tel URI's confusion about what it > really is, is getting us into trouble. > > If you think about the tel URI as a urn scheme, whereby resolution to an > actual set of communication resources is done using a resolution service > (ala DDDS), then it becomes fairly obvious (to me at least) that you > would simply never even put that URN into the of a presence > document, since it doesnt represent a communications service at all. If > anything, it's closer to a presentity identifier. Rather, you would put > the individual service URIs that result from the DDDS lookups. > > However, the tel URI is somewhat schizophrenic. Its not a URN, even > though it can use (but doesnt require) URN-like resolution services such > as enum. It's like a URN in that it can refer to an abstract name and be > resolved to a wealth of different URIs of many different schemes and > services. Its unlike a URN in that it is also used to refer to telephone > resources, and the implication of the tel URI is that "I can dial this > from a PSTN phone or enterprise phone and reach something". In that > aspect, its more like a protocol URI. > > What does this mean for presence? To be honest, in the discussion in the > data model draft, I have assumed the protocol URI meaning. That is, it > refers to a PSTN (or private network) circuit endpoint, period. That, of > course, is a BIG assumption, and something we should discuss. I would > propose that we keep this assumption and merely state it. In such a > case, it would not make sense for the recipient of a presence document > to look up such a tel URI in enum. Rather, it knows its a telephony > resource right away and can "dial it". This feels wrong to me. I think it is better viewed as "this CAN be reached via the PSTN, and MAY also be reachable other ways". At the very least, if I choose to use this published address, and there are ENUM entries for it, I should be free to use them (potentially making an e2e sip call). From a practical perspective, I think this means that if all I have is a PSTN phone, then I can consider this contact as one to try. If I have a sip device that supports tel uris and ENUM and has a pstn gateway, then I can also consider trying this contact. The tuple with this contact could show support for all sorts of media if it wants, and if my device supports those media then it might try them as well. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 16:35:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17582; Fri, 24 Sep 2004 16:35:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAwuD-00041q-JT; Fri, 24 Sep 2004 16:43:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAwf9-0005bU-W0; Fri, 24 Sep 2004 16:27:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAw4h-0000yC-Hh for simple@megatron.ietf.org; Fri, 24 Sep 2004 15:49:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09627 for ; Fri, 24 Sep 2004 15:49:45 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAwBj-0001K7-Nw for simple@ietf.org; Fri, 24 Sep 2004 15:57:05 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 24 Sep 2004 16:05:50 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8OJnCbx024106; Fri, 24 Sep 2004 15:49:13 -0400 (EDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALV00232; Fri, 24 Sep 2004 15:49:10 -0400 (EDT) Message-ID: <41547A36.8060703@cisco.com> Date: Fri, 24 Sep 2004 15:49:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] Presence Data Model: Identifying services References: <4152EFED.9030206@cisco.com> <1096029424.6605.18.camel@localhost.localdomain> <41542824.1010000@cisco.com> <1096041275.9809.70.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: SIMPLE WG , Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Aki Niemi wrote: > Inline. > > On Fri, 2004-09-24 at 16:59, ext Paul Kyzivat wrote: > >>>Hmm... If the scheme is that ambiguous, then perhaps its definition >>>needs to improve. >> >>Why? There is no particular reason why tel: should mean voice. We don't >>restrict sip: that way, and http: doesn't say much about what you can do >>either. (I can use http to exchange html, vxml, xcap, etc.) > > > There is a big difference. I can safely assume that for sip:, I am able > to send a SIP request and the other end will understand it; but probably > not an HTTP request, or let's say an SMTP message using that URI. > > I admit tel is more problematic, since it is more of a name, really > without a protocol attached to it, and sending a SIP request to it might > actually work (because we've defined what that means). But the inverse > isn't true, since POTS phones don't do IM or anything fancy like that. > That's why I think it's futile to build support for them on top of tel. > > BTW, there is also really no way to know whether I can send an SMS to > that telephone number (outside of recognizing it as a mobile number). > Which is one of the reasons an explicit smsto URI would be nicer... Well, you could advertise support for it in your presence document. :-) >>AFAIK, tel: is an addressing format and namespace. The following is from >> draft-ietf-iptel-rfc2806bis-09: >> >> The "tel" URI telephone number is not restricted in the type of >> termination point it refers to. The termination point can be in the >> public telephone network, a private telephone network or the >> Internet. The termination point can be fixed or wireless and address >> a fixed wired, mobile or nomadic terminal. The terminal addressed >> can support any electronic communication service (ECS) including >> voice, data and fax. > > Right, but I definitely don't think that IM or voice+IM session are > ECSs. SIP happens to have a linkage in that if I INVITE a tel URI with > appropriate media (e.g., voice or fax), then it may work if there is an > appropriate GW in place or a termination point that speaks SIP. Why not a SIMPLE-SMS gateway? >>>IMO the most obvious solution here is that if the endpoint wants to >>>advertize services other than (or in addition to) telephony, it >>>publishes a SIP or IM tuple as well as a tel tuple. Is there a >>>reason this would not work? >> >>I don't see a problem here, and so I don't feel a need for a solution. >> >>I agree that other address forms are probably desirable in this case, >>for a variety of reasons. But that doesn't mean we should >>automatically assume tel: implies voice telephony and only that. > > I think we have to assume tel implies some telephony, or ECS service > (whatever that means). If a presentity wants to advertize services > beyond those, then it is only reasonable that those other contacts are > also shown in presence. I think it is reasonable to assume that a tel: address is reachable via the PSTN, and hence presumably supports some media usable in that way. But it may also support other media when accessed via a protocol (like SIP) that supports them. >>One place where this situation may well come up is when the tel: uri >>is >>used as the presentity address. (Something that should be ok, and >>makes >>sense to use if you are a client and that is all you have.) It may be >>that the user doesn't want to expose device addresses, and so provides >>only the presentity address back as the contact in the tuple(s). > > > I don't understand what the problem there is. Even if tel URI was > allowed as the entity attribute in PIDF (which it isn't AFAIK) I'm not sure. The PIDF xml schema says that it can be anyURL. The description of the element says: "The value of the 'entity' attribute is the 'pres' URL of the PRESENTITY publishing this presence document." But AFAIK "is" isn't normative, so the schema takes precedence. I know use of sip: urls is common, so I see no reason why tel: couldn't also be used. Of course there would be the issue of discovering the presence server when using a tel: uri as a presentity address. If I know how to use sip for presence, then an enum mapping from the tel address to a sip address would do the trick. But then I suppose the PS would use the sip address as the entity. > then that > presence document would simply state the status of telephony services, > nothing more. Why? It can describe everything that is available. And it can use the tel address in the tuples if it likes. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 16:56:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19607; Fri, 24 Sep 2004 16:56:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAxEJ-0004aw-KS; Fri, 24 Sep 2004 17:03:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAwkd-0001Nb-HQ; Fri, 24 Sep 2004 16:33:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAwU6-0007EX-0U for simple@megatron.ietf.org; Fri, 24 Sep 2004 16:16:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13878 for ; Fri, 24 Sep 2004 16:16:00 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAwb8-0002ps-BP for simple@ietf.org; Fri, 24 Sep 2004 16:23:19 -0400 Received: from panther.cs.columbia.edu (IDENT:MvzuchwViXe6235q+D89HLD6/LgnhhQJ@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8OKFlwG006444 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 24 Sep 2004 16:15:48 -0400 (EDT) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i8OKFleO002420; Fri, 24 Sep 2004 16:15:47 -0400 Message-ID: <4154806D.3010602@cs.columbia.edu> Date: Fri, 24 Sep 2004 16:15:41 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: meaning of tel URI in presence data model, was: Re: [Simple] Presence Data Model: Identifying services References: <4152EFED.9030206@cisco.com> <1096029424.6605.18.camel@localhost.localdomain> <41542824.1010000@cisco.com> <41543F2A.9070708@dynamicsoft.com> <415474FC.6090809@cisco.com> In-Reply-To: <415474FC.6090809@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.9.24.0 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0, __cbl.abuseat.org_TIMEOUT ' X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit > > This feels wrong to me. Agreed. > > I think it is better viewed as "this CAN be reached via the PSTN, and > MAY also be reachable other ways". At the very least, if I choose to use > this published address, and there are ENUM entries for it, I should be > free to use them (potentially making an e2e sip call). To rephrase slightly: the tel: URI simply says "this is a service that is identified by an E.164 number" and adds a level of indirection to allow a separate instance to do the binding to one or more instances implementing this service, where the binding resolution is performed either at the outbound proxy (if used in a SIP device, using any method including but not limited to ENUM) or the end system (using ENUM or direct dial). It probably helps if that number is indeed dialable (with number translation into a dial string) by a regular, analog phone controlled by some TAPI interface. The usual phone number caveats apply: it may whistle at you, it may be an SMS-only number, etc. I don't see why this level of indirection is problem or requires further special-casing within the presence data model. > > From a practical perspective, I think this means that if all I have is > a PSTN phone, then I can consider this contact as one to try. If I have > a sip device that supports tel uris and ENUM and has a pstn gateway, > then I can also consider trying this contact. The tuple with this > contact could show support for all sorts of media if it wants, and if my > device supports those media then it might try them as well. > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 17:04:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20315; Fri, 24 Sep 2004 17:04:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAxLz-0004nT-CI; Fri, 24 Sep 2004 17:11:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAx7W-0004aN-P9; Fri, 24 Sep 2004 16:56:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAwlr-00025R-6d for simple@megatron.ietf.org; Fri, 24 Sep 2004 16:34:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17326 for ; Fri, 24 Sep 2004 16:34:21 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAwsu-0003xN-3l for simple@ietf.org; Fri, 24 Sep 2004 16:41:41 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2004 13:46:45 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8OKY4wr017496; Fri, 24 Sep 2004 13:34:07 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALV03921; Fri, 24 Sep 2004 16:34:03 -0400 (EDT) Message-ID: <415484BB.4010807@cisco.com> Date: Fri, 24 Sep 2004 16:34:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: [Simple] Presence Data Model: Identifying services References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8a07f64def4bd8598257bc442beb9d Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 398dc098b38497efe55f044562a219e7 Content-Transfer-Encoding: 7bit Markus, I largely agree with the comments that Jonathan made. He suggested that the problem at hand is that your PTT isn't really sip if it can't interoperate with a regular sip device. That may be a bit extreme, but not too far off. As I suggested in an earlier reply, you could model this by indicating that you don't support voice, and instead describe some other capability. Better yet would be to actually support voice. How hard would it be to create a voice:ptt transcoder. Then the situation would be much like a codec mismatch. I don't really imagine you would do this right now, but that may be the long term path to true interoperability. More comments below. Paul Markus.Isomaki@nokia.com wrote: > Hi Paul, > > Thanks for your comments. > > I guess what we both want to accomplish is this: > > Allow the watcher to better understand whether and how it is able to communicate with a "service" or "communication mean" that is advertised by the presentity. > > The current approach is to list as many characteristics and parameters of the service as possible, so that the watcher has as much information as possible. In theory this works well, as long as there is some agreed set of characteristics for each possible service. In practice there are no guarantees, since some essential info, such as codec support, is probably discovered only by trial and error. The concept still works well as long as the probability of a "false positive" is reasonably low. > > One idea might be that the presentity should be able to declare some capabilities as mandatory/essential, i.e. saying like "if you don't support at least capabilities A and B, please don't contact me, since there is no value in this from my point of view". An example might be PTT, where the presentity could declare support for "voice", "half-duplex", "INVITE, ..." and floor control "foo", and might insist that even if the watcher supported the same except floor control "bar", the communication should not be attempted. Obviously it would be in the power of the clients and users to decide what to declare as essential and whether to obey those declarations, but at least it would give a hint whether things would work in a reasonable way or not. The ability to declare something as mandatory/essential should apply also to characteristics not understood by the watcher, e.g. if the watcher in the example is a normal VoIP client able to do half-duplex but with no understanding of a ny type of floor control (except maybe on layer 9 ;-), it could still see that "some feature I don't understand seems to be mandatory, so there is a high probability that the communication will not work". In this way the evil proprietary client could hint "please don't call me even though I'm addressable with SIP unless you know what xyz and zyx are, since if you don't, the outcome may not be anything useful". I fear where this approach might lead. I think we will then end up with complex predicates. (We have more than enough trouble that way with callerprefs, and we don't have a comparable description of calleeprefs.) This would be especially problematic if it meant that the presence UI needed to display these constraints. (It would be slightly less bad if the subscriber application just applied the constraints to the capabilities it knows are available locally in order to filter what is displayed.) > Is there any chance of adding this kind of mechanism? I guess it would be some kind of attribute that would apply to all elements describing service characteristics. I believe it should be part of the data model, so that the designers of the proprietary extensions would know how to use it. I really hope we don't need to go there. > The hard part I see is keeping the standardized characteristics up-to-date and useful. For instance adding "floor control protocol" etc. > Markus > > > >>-----Original Message----- >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: 23 September, 2004 18:47 >>To: Isomaki Markus (Nokia-TP/Espoo) >>Cc: Stefan.Goeman@siemens.com; simple@ietf.org >>Subject: Re: [Simple] Presence Data Model: Identifying services >> >> >>I have comments both to Markus' original posting and to the ensuing >>discussion. So I will just insert inline in the latest >>response I have. >> >> Paul >> >>Markus.Isomaki@nokia.com wrote: >> >>>Hi Stefan, >>> >>>Comments back to you inline. >>> >>>(Yes, I absolutely agree with you on the usefulness of the >> >>Presence Data Model draft and that it should have been the >>starting point, at least right after PIDF.) >> >>> >>>>-----Original Message----- >>>>From: simple-bounces@ietf.org >>>>[mailto:simple-bounces@ietf.org]On Behalf >>>>Of ext Goeman Stefan >>>>Sent: 23 September, 2004 14:42 >>>>To: 'simple@ietf.org' >>>>Subject: RE: [Simple] Presence Data Model: Identifying services >>>> >>>> >>>>Hello, >>>> >>>>Comments inline >>>> >>>>P.S.: In general, I find the Presence Data model draft a good >>>>document. This >>>>is how things should have started in the first place. >>>> >>>>Greetings, >>>>Stefan. >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: simple-bounces@ietf.org >>>>>[mailto:simple-bounces@ietf.org] On Behalf Of >>>> >>>>Markus.Isomaki@nokia.com >>>> >>>> >>>>>Sent: donderdag 23 september 2004 10:10 >>>>>To: simple@ietf.org >>>>>Subject: [Simple] Presence Data Model: Identifying services >>>>> >>>>> >>>>>Hi all, >>>>> >>>>>I have a comment on Presence Data Model draft about the >>>>>identification/characterization of services. (I know this has >>>>>been discussed for a while already, but I still think the >>>>>current way is somewhat unadequate.) >>>>> >>>>>The current Data Model draft says: >>>>> >>>>> In this model, services are not explicitly enumerated. That is, >>>>> there is no "service" attribute with values of "ptt" or >>>>>"telephony". >>>>> Rather, the service is identified in one of two ways. In >>>>>many cases, >>>>> the URI scheme is a clear indicator of service. An "sms" >>>>>URI clearly >>>>> indicates SMS, and a "tel" URI clearly indicates >>>>>telephony. >>>> >>I don't find the scheme as clearcut as that. I don't think one should >>assume "tel" indicates telephony. It perhaps does imply >>reachability via >>various telephony protocols for purpose of voice >>communications, but is >>not exclusive to that. If the tel: URI can be mapped to a sip >>endpoint >>and protocol, then non-voice, non-telephony capabilities are >>not excluded. >> >>For instance, it may prove convenient to publish a tel URI for a sip >>endpoint that is capable of both voice and IM. Then calls via >>the PSTN >>will work, calls from a sip audio phone will work, calls from another >>voice+im client will have access to voice and IM. >> >> >>> For some >> >>>>> URIs, there may be many services available, for example, >>>> >>>>SIP. For >>>> >>>> >>>>> those services, each service has a set of >>>> >>>>characteristics, each of >>>> >>>> >>>>> which has a well-defined meaning, such that a system can >>>>> unequivocally determine whether or not the service has that >>>>> characteristic. This is discussed in more detail in [5]. >>>>> >>>>>I agree that the contact URI scheme is the most important >>>>>piece of information to distinguish what is the "service". >>>>>(There are some gaps here too, since e.g. the URI schemes for >>>>>SMS or MMS do not even exist, and there may be other non-IETF >>>>>protocols that face the same problem.) However, I'm not >>>>>convinced that listing the signaling/media characteristics of >>>>>the end-point or service really gives enough information to >>>>>the watcher to really determine if it can communicate with >>>>>the advertised service/application. >>>>> >>>>>The refenced draft [5] has a following example: >>>>> >>>>>5.6 Walkie-talkie >>>>> >>>>> The walkie-talkie service allows real-time voice communication >>>>> between participants. Only one participant can speak at a >>>>>time; that >>>>> is, communication is half-duplex. Typically, >>>> >>>>participants press a >>>> >>>> >>>>> button to indicate that they are ready to speak, although other >>>>> mechanism (e.g. voice activation) are occasionally used. >>>>> >>>>> Support for the Walkie-Talkie service can be deduced by >>>>>observing the >>>>> presence of a contact URI with a scheme of "sip:", >>>> >>>>associated with >>>> >>>> >>>>> the following minimal set of capabilities: >>>>> half INVITE,ACK,BYE,CANCEL >>>>> >>>>>Presumably this is the same as the service sometimes called >>>>>Push-to-Talk (PTT, PoC). The concrete problem is that there >>>>>are several _non-interworking_ variants of this service, that >>>>>still all would match the characteristics listed above, as >>>>>the _SIP_ part might still be standard, at least for some >>>>>methods etc. But still the communication would fail even if >>>>>the tuple looks OK. >>>> >>>>I don't think I understand you here. I would expect that if >>>>both end-point >>>>SIP US support exactly the same methods, the SIP UA should >>>>also be able to >>>>handle those SIP method. Or, to phase it in another way, both >>>>end-point >>>>should be able to communicate with each other only based on >>>>using these >>>>capabilities. >>>> >>> >>> >>>To some extent that might be possible, but there might be >> >>differences e.g. in floor control etc., which make the >>service still practically unusable, which means that the >>presence document shouldn't give the impression that the >>communication will work. Obviously it is possible to list all >>those additional characteristics as well (and this might be a >>good idea too), but for instance if presence of a network >>game is published, it is easier to _explicitely_ tell what >>the game is by providing some sort of unique id which would >>be only meaningful to those similar game clients. >> > >> >>>>>(Also if I saw the characteristics above, >>>>>I could as well determine that they describe normal VoIP >>>>>application running in (very) some old PC with half-duplex >>>>>audio drivers, so I claim the service description is hard to >>>>>make unambiguous in the first place.) >>>> >>I think the goal should be that all of these are at least minimally >>interoperable. I ought to be able to call a PTT contact from >>a regular >>voice phone and have *something* reasonable happen. (Maybe it is just >>oneway voice, with the non-ptt caller never getting the >>floor, but that >>may be better than nothing. >> >>I think the real problem in this case is not with the capability >>approach. It is that the 'duplex' capability is >>underspecified. There is >>no explanation of how a pair of half duplex endpoints (or one >>half-duplex and one full-duplex endpoint) agree on who can talk. >> >>In the case of the 'voice' capability, it is understood that >>having both >>endpoints support voice isn't enough to support >>communication. There is >>an SDP negotiation of codecs, etc. that either succeeds or >>fails. There >>should be something similar for half-duplex. >> >> >>>>I also have the impression that it will be difficult to >>> >>determine the >> >>>>services merely based on the SIP methods (and ...) supported >>>>by the SIP UA. >>>>It possibly might mean that the SIP-based ptt-service on my >>>>mobile phone >>>>might be mapped onto some communication service on your PC. >>>>Then, I wonder >>>>who will be responsible for such kind of mapping? Only the >>>>end terminals, or >>>>is support from the network, presence server, necessary? And, >>>>how will one >>>>service in one domain be mapped into a service in another >>>>domain? I believe >>>>there are some open issues here. >>> >>The intent is that capabilities have common meanings in all >>domains, so >>they don't need to be mapped. I don't see why there should be any >>binding between services and domains. >> >>In the general case one should assume that there are devices >>of widely >>varying capabilities in every domain, and that they know best >>what they >>are capable of. So the device should be the one deciding if a contact >>with and advertised set of capabilties is something it wants >>to attempt >>communication with. >> >>In some environment where there is an intermediary in front >>of a device >>that understands the device and acts on its behalf, then I suppose it >>could make these decisions. But I would consider that the odd case. >> >> >>>I think that it is fully OK to describe some rather simple >> >>things using characteristics, but in many cases applications >>are more complex. >> >>Clearly we have chosen not to describe capabilities if full detail. >>(E.g. we don't publish codec support.) Because of this, there is the >>possibility that we make a wrong decision about ability to >>communicate >>and it doesn't get discovered until we try. >> >>This is ok when the expected probability of failure is low. (We >>generally expect that there will be some codec in common, or that one >>end or the other will be able to introduce a transcoder.) >> >> >>>>>I think the main point of a service tuple is to give the >>>>>watcher enough information to know whether he can really >>>>>communicate & interoperate with the advertised service. Given >>>>>that many services taht are using SIP also have propritary or >>>>>non-SIP features, I don't think the current approach is enough. >>>> >>In cases where the existing capabilities aren't sufficient to >>ensure a >>good probability of communication, then we should indeed >>consider adding >>additional capabilities. >> >>But I continue to object to the notion of "service" as the way to do >>that, because it conveys no semantics about what the >>capability is that >>it describes. >> >> >>>>Do you have an example of a service that uses SIP and also has non >>>>SIP-features? If your service also uses non-SIP features, >>> >>you can not >> >>>>determine the type of service by only looking at the SIP >>> >>capabilities >> >>>>supported by the SIP UA. Some indication of that non-SIP >>>>feature should also >>>>be present in the presence document. >>>> >>> >>> >>>True, and since some of those non-SIP features might not be >> >>based on (IETF) standards, it might be good to have the >>possibility for the developers of such applications to have a >>short cut of saying what the app really is, rather than >>having to list characteristics. In the end, some applications >>are really not even meant to work with any other than the >>exactly same application, for instance some networking games. >> >>If the intent is to define a closed world, where >>interoperability is not >>even considered a desirable feature, then I agree. I think that may >>indeed be the case for proprietary games. >> >>But for something like PTT, while it might be in the best interest of >>the maker of a particular PTT solution to keep it closed, I >>don't think >>it is in the best interest of society or the IETF that this >>happen. This >>is precisely the forum in which we try to prevent that from happening. >> >> >>>>>Of course each of these proprietary services are allowed to >>>>>define additional status or tuple-level extensions to PIDF. >>>> >>>>Yes, you can always extend the PIDF. My comment here is that >>>>this might lead >>>>to an "explosion" of applications or services. It will >>>>certainly not help >>>>interoperability. >>> >>My point precisely. >> >> >>>And who would standardize such characteristic definitions. >> >>It has already taken a couple of years to standardize even >>"prescaps", which is just a starting point. >> >>> >>>>>However, I would like to have some kind of "service >>>>>identifier" as part of the basic framework so that this could >>>>>be done in a consistent manner. I think it would help >>>>>especially in making of authorization and composition rules >>>>>more simple. The current "class" attribute is way too >>>> >>>>loosely defined. >>>> >>>> >>>>>So the concrete proposal is to include in RPID a "service id" >>>>>element that would have a vendor-specific namespace, similar >>>>>to e.g. vendor-specific XCAP AUIDs. So for instance the >>>>>SIP-based PTT app from vendor xyz.com would have, e.g. >>>>>com.xyz.ptt >>>>>while the PTT app compliant with OMA would have, e.g. >>>>>com.openmobilealliance.ptt >>>> >>I am not fond of this solution. Done this way, we have defined an >>element that has no semantics at all, only syntax. >> >>I would rather see vendor specific extensions to PIDF. At >>least then the >>people that support an extension will understand what it means. >> >>But I would rather see people come forward and do the hard work of >>publicly defining new capabilities so that independent >>implementations >>can use them in an interoperable way. >> >> >>>>In general, I could agree with that approach. However, I >>>>don't see a reason >>>>why the vendor specific SIP-based PTT should be different >>> >>>>from the OMA based >>> >>>>PTT. Simply define one PTT, based on the SIP UA capabilities. >>>> >>> >>> >>>Well, for instance Nokia has a prorietary PTT application, >> >>which uses SIP INVITE etc., so users are essentially >>addressed with sip: URI. However, it has some floor control, >>media etc. features which make it basically non-interoperable >>with clients that are not specifically following that >>proprietary spec. >> >>This is a problem, not a good thing. I realize it has to >>happen as part >>of the development process, but the goal should be to get out >>of it as >>fast as possible. >> >>I would hope that endpoints supporting this would be >>described as well >>as possible using existing capabilities, and that a >>reasonable effort be >>made to do something reasonable when some other sip device connects. >> >>If you really can't deal with a regular voice caller at all, then I >>would suggest, as a transitional step, saying that you don't support >>voice, and then advertising some proprietary capability as an >>alternative to voice. >> >> >>>OMA PTT is closer to standard IETF SIP. Unless there is >> >>some conversion, it does not work with Nokia PTT directly. >>There should be some way for distinguishing these two in a >>presence document, so that there won't be confusion. I think >>the current idea is to do some kind of proprietary PIDF >>extensions, but in my opinion a standard XML element in RPID >>to tell this kind of information would be better, also for >>the purposes of authorization rule making. >> >>See above for what I think you could do for now. The same issues may >>apply to OMA PTT, and a similar solution could be applied to it. >> >>Hopefully somebody will come up with a PTT that can be dealt >>with more >>gracefully. I think that work should be done on better defining >>half-duplex, so that it can be used in conjunction with voice to >>describe PTT. But it may just turn out to be the wrong thing. >>Maybe we >>need a "floor-control" capability. >> >> >>>>>in _addition_ to describing sip:, half-duplex audio, and the >>>>>supported methods. Now: >>>>>1.) Watcher having one of those apps could see right away >>>>>whether it is possible to communicate >>>>>2.) Composer getting PUBLISHes from 2 sources could >>>>>immediately know that they are from a similar app >>>>>3.) The app could set its authorization rules using the unique id. >>>>> >>>>>The main downside I can see in this approach that if there >>>>>are two different proprietary apps that indeed could >>>>>communicate at least partially, the watcher might make a >>>>>conclusion that communication is not possible baed on >>>>>different service-id. >>>> >>This is my concern as well. >> >> >>> However, in this case the watcher still >> >>>>>would have the characteristics visible and could determine >>>>>that some interworking could be achieved. >>>> >>>>Personally, I don't think it is a good idea that an end-user >>>>should make >>>>such decission. If I get a presence document that indicates >>>>that another >>>>person is able to receive some type of communication, I >>>>expect that that >>>>type of communication would actually work when I use it. >>> >>With high probability. There are no guarantees with presence. For >>instance see my mention above of codecs. >> >> >>>Exactly right. If you are an application who does not >> >>necessarily aim for interoperability, but still uses sip:, >>INVITE etc., you should be able to explicitely say so. >> >>And you can, without a special notion of service. >> >> >>>>>For this kind of >>>>>reasons there should be careful text about when to use >>>>>service-id in the first place, and what can be determined from it. >>>>> >>>>>Does someone think that this is an absolutely bad idea? If >>>>>so, how would you envision solving the issues discussed above? >>>> >>I still don't buy this. >> >> >>>>I think more care should be taken in mapping SIP UA >>>>capabilities into actual >>>>services. That is not so clear to me! >>> >>>The idea is nice, but I don't see a problem in _addition_ >> >>defining the application with something like >>"com.openmobilealliance.ptt" or "com.nokia.ptt", if that kind >>of profile would have more meaning than the list of characteristics. >> >>I am still opposed to defining an attribute with no semantics. >>We have been around this so many times that I am quite >>certain that it >>will never be possible to get a useful agreement on what >>"service" means. >> >>If it is introduced, I expect it to have problems like those >>of the INFO >>method. (The arguments for introducing it seem similar.) >> >> Paul >> >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Sep 24 17:13:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21096; Fri, 24 Sep 2004 17:13:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAxV7-00052b-5z; Fri, 24 Sep 2004 17:21:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAxAR-0005M5-Ik; Fri, 24 Sep 2004 16:59:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAwxy-0001JA-UE for simple@megatron.ietf.org; Fri, 24 Sep 2004 16:46:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18629 for ; Fri, 24 Sep 2004 16:46:53 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAx52-0004Iu-Vm for simple@ietf.org; Fri, 24 Sep 2004 16:54:13 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2004 13:58:59 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8OKkISI021889; Fri, 24 Sep 2004 13:46:19 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALV04906; Fri, 24 Sep 2004 16:46:19 -0400 (EDT) Message-ID: <4154879B.4010908@cisco.com> Date: Fri, 24 Sep 2004 16:46:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nancy Greene (QC/EMC)" Subject: Re: [Simple] Presence Data Model: Identifying services References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Nancy Greene (QC/EMC) wrote: > Paul said: > >>I think the real problem in this case is not with the capability >>approach. It is that the 'duplex' capability is underspecified. There is >>no explanation of how a pair of half duplex endpoints (or one >>half-duplex and one full-duplex endpoint) agree on who can talk. > > >>the case of the 'voice' capability, it is understood that having both >>endpoints support voice isn't enough to support communication. There is >>an SDP negotiation of codecs, etc. that either succeeds or fails. There >>should be something similar for half-duplex. > > > I have been thinking about this too. When it is just a pair of terminals, each could use their own mechanism to not start an RTP session if it detects that the other end has started one first. If I understand you, that isn't half duplex - it is simplex with the direction negotiated. I suppose you could use reinvites to request and transfer the floor, but I don't imagine that would work very well. > But don't we need the duplex info as an attribute in the sdp as well as in a feature tag? It may only apply to one of the media types negotiated. Probably. Its partially there (in the form of sendonly/recvonly) if you want to manage the floor using offer/answer (ugh!). Otherwise something else is needed in order to negotiate the need for floor control. I think the conferencing work also has mechanisms to negotiate the establishment of a floor control channel, but I don't think it is SDP. As long as there is some way of negotiating the floor control in an offer/answer, a PTT endpoint can refuse a call that fails to do so. Then the incompatibility is comparable to codec incompatibility. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Sep 25 09:27:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26363; Sat, 25 Sep 2004 09:27:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBChh-0003QQ-Ct; Sat, 25 Sep 2004 09:35:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBCXx-000316-Ls; Sat, 25 Sep 2004 09:25:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBCUT-0002YN-B6 for simple@megatron.ietf.org; Sat, 25 Sep 2004 09:21:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26155 for ; Sat, 25 Sep 2004 09:21:27 -0400 (EDT) Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBCbc-0003L4-TO for simple@ietf.org; Sat, 25 Sep 2004 09:28:56 -0400 Received: from [69.170.16.83] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7634882 for simple@ietf.org; Sat, 25 Sep 2004 09:21:18 -0400 Message-Id: <5.1.0.14.0.20040925091622.024de338@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 25 Sep 2004 09:21:00 -0400 To: simple@ietf.org From: "Joel M. Halpern" Subject: Re: [Simple] Presence Data Model: Identifying services In-Reply-To: <415484BB.4010807@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 I think this is an overstatement. To keep it simple, a sip client with only a speaker and microphone can not effectively participate in a service which involves a video stream, even to be just the receiver. He can attempt a media negotiation, but it will fail. Similarly, if the PTT floor control is handled in the RTP / STCP (as some of the proposals do), then the SIP is compliant, but the negotiation (assuming that the SDP properly represents the details) will fail. To call this "not SIP" seems very odd. The SIP would be fully compliant. Now, one can view the presence properties as a hint, and say "sometimes it is not enough information". In fact, for at least some cases we need to say that. But we should not pretend that the contact URI always properly (much less unambiguously) identifies the service. Yours, Joel M. Halpern At 04:34 PM 9/24/2004 -0400, Paul Kyzivat wrote: >Markus, > >I largely agree with the comments that Jonathan made. > >He suggested that the problem at hand is that your PTT isn't really sip if >it can't interoperate with a regular sip device. That may be a bit >extreme, but not too far off. > >As I suggested in an earlier reply, you could model this by indicating >that you don't support voice, and instead describe some other capability. > >Better yet would be to actually support voice. How hard would it be to >create a voice:ptt transcoder. Then the situation would be much like a >codec mismatch. I don't really imagine you would do this right now, but >that may be the long term path to true interoperability. > >More comments below. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 27 06:49:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18567; Mon, 27 Sep 2004 06:49:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBtCO-0002sE-12; Mon, 27 Sep 2004 06:57:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBszk-00078D-6i; Mon, 27 Sep 2004 06:44:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBsyo-00071h-Ub for simple@megatron.ietf.org; Mon, 27 Sep 2004 06:43:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18305 for ; Mon, 27 Sep 2004 06:43:35 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBt6Q-0002nP-1I for simple@ietf.org; Mon, 27 Sep 2004 06:51:30 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8RAhV115223; Mon, 27 Sep 2004 13:43:31 +0300 (EET DST) X-Scanned: Mon, 27 Sep 2004 13:42:54 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i8RAgsxB000507; Mon, 27 Sep 2004 13:42:54 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00mkx5RF; Mon, 27 Sep 2004 13:42:24 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8RAgMY25603; Mon, 27 Sep 2004 13:42:22 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 27 Sep 2004 13:42:02 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 27 Sep 2004 13:42:01 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe023.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 27 Sep 2004 13:42:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Review of draft-ietf-simple-message-sessions-08 - Chunking Date: Mon, 27 Sep 2004 13:42:00 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B64B@esebe056.ntc.nokia.com> Thread-Topic: [Simple] Review of draft-ietf-simple-message-sessions-08 - Chunking Thread-Index: AcSiWQSvUA4oeGgpQXCgbel9G0lerwCJSpow To: , X-OriginalArrivalTime: 27 Sep 2004 10:42:00.0803 (UTC) FILETIME=[9EAA9330:01C4A47E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Paul Kyzivat > Sent: 24.September.2004 19:20 > To: 'simple@ietf.org' > Subject: [Simple] Review of draft-ietf-simple-message-sessions-08 - > Chunking >=20 >=20 > Out approach to chunking has evolved thru the versions, and=20 > the document > doesn't seem wholely clear and consistent about what we have=20 > arrived at. > In fact, I am not entirely certain I know fully what we have decided, > and I can't figure it out for certain from the document. I=20 > would propose > specific wording changes, but first I want to get clarification about > how we think it should now work. >=20 > Based on scattered information in the doc, and reading between the > lines, and factoring in stuff from conversations along the way, I > *think* the following is intended: >=20 > - only SEND messages are chunkable >=20 > - there are two kinds of chunks: interrruptible and uninterrupible. >=20 > - a chunk is uninterruptible if it has a Byte-Range header with a > numeric range-end. >=20 > - other chunks are interruptible. (No Byte-Range, or a Byte-Range > with a range-end of "*".) >=20 > - uninterruptible chunks MUST NOT have a range-end greater than 2048. >=20 > - chunks other than the last SHOULD (or MUST?) have a body ('data' > in the syntax) of length exactly 2048. If SHOULD, what is a > valid reason to violate? >=20 > - responses never have bodies at all. Requests other than SEND > may have a body but are unchunkable. The presence of a Byte-Range > in a request other than SEND says nothing about the body of that > request. (In REPORT it refers to the SEND being reported on. > See separate thread on Byte-Range.) This at best seems irregular > and weird. >=20 > Section 6.3.1 says: "it is possible the body is shorter than the > range-end field indicates. This can occur if the sender interrupted a > SEND request unexpectedly." Based on what I have interpretted above, > this is no longer possible. (To be interrupted it must have had a > range-end of "*".) I think it is still possible, but it means that it was an abnormal = behaviour. Perhaps we should include some text discussing a recovery = mechanism for this case. /Hisham >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 27 07:04:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19351; Mon, 27 Sep 2004 07:04:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBtQx-00038O-8P; Mon, 27 Sep 2004 07:12:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBtI3-0000Br-Sf; Mon, 27 Sep 2004 07:03:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBt9y-00084t-2C for simple@megatron.ietf.org; Mon, 27 Sep 2004 06:55:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18840 for ; Mon, 27 Sep 2004 06:55:06 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBtHY-0002y7-HT for simple@ietf.org; Mon, 27 Sep 2004 07:03:02 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8RAt2g28367; Mon, 27 Sep 2004 13:55:02 +0300 (EET DST) X-Scanned: Mon, 27 Sep 2004 13:54:47 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i8RAslH1014592; Mon, 27 Sep 2004 13:54:47 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00sSNeZK; Mon, 27 Sep 2004 13:54:44 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8RAshY06254; Mon, 27 Sep 2004 13:54:43 +0300 (EET DST) Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 27 Sep 2004 13:54:39 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 27 Sep 2004 13:54:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Review of draft-ietf-simple-message-sessions-08 -Overlapping Chunks Date: Mon, 27 Sep 2004 13:54:38 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B64D@esebe056.ntc.nokia.com> Thread-Topic: [Simple] Review of draft-ietf-simple-message-sessions-08 -Overlapping Chunks Thread-Index: AcSiVpL8sLTJvqzQQki/1oy3RzhaWgCKPjdg To: , X-OriginalArrivalTime: 27 Sep 2004 10:54:39.0199 (UTC) FILETIME=[62B49EF0:01C4A480] X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Paul Kyzivat > Sent: 24.September.2004 19:21 > To: 'simple@ietf.org' > Subject: [Simple] Review of draft-ietf-simple-message-sessions-08 > -Overlapping Chunks >=20 >=20 > Section 6.3.1 discusses how to handle the receipt of=20 > overlapping chunks, > specifying that the last received copy of any particular byte wins. I > don't think this is good. >=20 > If the overlapping chunks contain consistent data then it=20 > doesn't matter > which takes precedence. If they contain conflicting data then=20 > reordering > of chunks can affect the result unpredictably. This rule also prevents > the recipient from rendering a byte when it and all preceding=20 > bytes have > been received. >=20 > I think it should be permissible for the recipient to check for > inconsistency in the overlapping case, and report an error if=20 > so. We may > want to require this checking. (Since it typically won't happen it > shouldn't have a performance impact.) Since it typically won't happen, I would argue that we don't need to = complicate the protocol to handle it. /Hisham >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 27 07:10:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19563; Mon, 27 Sep 2004 07:10:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBtWK-0003DD-OC; Mon, 27 Sep 2004 07:18:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBtIS-0000Gb-FG; Mon, 27 Sep 2004 07:03:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBtDX-0008LT-Rq for simple@megatron.ietf.org; Mon, 27 Sep 2004 06:58:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18982 for ; Mon, 27 Sep 2004 06:58:48 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBtL8-00031W-Cb for simple@ietf.org; Mon, 27 Sep 2004 07:06:43 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8RAwhL27700; Mon, 27 Sep 2004 13:58:43 +0300 (EET DST) X-Scanned: Mon, 27 Sep 2004 13:58:30 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i8RAwUgf028706; Mon, 27 Sep 2004 13:58:30 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00fjuQhJ; Mon, 27 Sep 2004 13:58:21 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8RAwFS14136; Mon, 27 Sep 2004 13:58:15 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 27 Sep 2004 13:58:15 +0300 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 27 Sep 2004 13:58:14 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 27 Sep 2004 13:58:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Review of draft-ietf-simple-message-sessions-08 - Byte Ranges in REPORTs Date: Mon, 27 Sep 2004 13:57:49 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B64E@esebe056.ntc.nokia.com> Thread-Topic: [Simple] Review of draft-ietf-simple-message-sessions-08 - Byte Ranges in REPORTs Thread-Index: AcSiVtS3wHz1eh6tQ+KMtuqsOz6spwCKcclg To: , X-OriginalArrivalTime: 27 Sep 2004 10:58:14.0996 (UTC) FILETIME=[E354A140:01C4A480] X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable I agree. The situation is further complicated when a relay decides to = re-chunk. The relay then has to consume the REPORTs and generate it own = to pass upstream. /Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Paul Kyzivat > Sent: 24.September.2004 19:21 > To: simple@ietf.org > Subject: [Simple] Review of=20 > draft-ietf-simple-message-sessions-08 - Byte > Ranges in REPORTs >=20 >=20 > I am really confused about how byte ranges are supposed to work in > reports, and I suspect we are permitting a bunch of nonsense. >=20 > Fundamentally, a message can only be considered a success if all its > bytes are received successfully. If it is to be positively=20 > acknowledged > with success reports, then there must be success reports covering > every byte. Is there any point in sending a success report=20 > for less than > the entire message? It doesn't help the receiver, and actually makes > more work because it then requires keeping track of what=20 > bytes have been > confirmed. And it doesn't ease the job of the sender, who could easily > just wait until all has been received before sending the=20 > success report. >=20 > The flip side is that a message fails if a single byte fails. At that > point it does no good to know that other parts succeeded or failed. So > while it makes sense to send a failure report based on problems with a > single chunk, there is little value in saying which byte range failed. >=20 > Bottom line: unless I have missed something, there is no reason for > Byte-Range in REPORT or responses. A success report should=20 > only be sent > after all the chunks of a message have been received. A=20 > failure report, > or an error status, can be sent at the time the failure of a single > chunk is known, but need not identify the byte range. (In that case, > maybe the Byte-Range could be optional for debugging purposes only.) >=20 >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 27 07:12:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19720; Mon, 27 Sep 2004 07:12:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBtYg-0003GR-V2; Mon, 27 Sep 2004 07:20:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBtIr-0000IP-EC; Mon, 27 Sep 2004 07:04:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBtFt-0008Uz-PF for simple@megatron.ietf.org; Mon, 27 Sep 2004 07:01:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19246 for ; Mon, 27 Sep 2004 07:01:14 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBtNU-00035U-Ao for simple@ietf.org; Mon, 27 Sep 2004 07:09:09 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8RB19109841; Mon, 27 Sep 2004 14:01:09 +0300 (EET DST) X-Scanned: Mon, 27 Sep 2004 14:00:35 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i8RB0ZHB003539; Mon, 27 Sep 2004 14:00:35 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00bb7cqs; Mon, 27 Sep 2004 14:00:33 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8RB0OS15465; Mon, 27 Sep 2004 14:00:24 +0300 (EET DST) Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 27 Sep 2004 14:00:17 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 27 Sep 2004 14:00:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Review of draft-ietf-simple-message-sessions-08 - max-size Date: Mon, 27 Sep 2004 14:00:02 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B64F@esebe056.ntc.nokia.com> Thread-Topic: [Simple] Review of draft-ietf-simple-message-sessions-08 - max-size Thread-Index: AcSiVxqWKNpgXiGjQoaDmVDXYDhwwwCKe6zg To: , X-OriginalArrivalTime: 27 Sep 2004 11:00:16.0268 (UTC) FILETIME=[2B9D44C0:01C4A481] X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable I believe it applies to a message (spread across 1 to n SENDS requests, = i.e. chunks). Hisham > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Paul Kyzivat > Sent: 24.September.2004 19:21 > To: simple@ietf.org > Subject: [Simple] Review of draft-ietf-simple-message-sessions-08 - > max-size >=20 >=20 > Section 7.1 says: "An endpoint MAY indicate the maximim size message > they wish to receive using the max-size a-line attribute". >=20 > Does this apply only to a *message* - namely the content of a SEND > request? Or does this apply to any and all requests (including future > extensions) that have content? >=20 >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 27 07:51:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22123; Mon, 27 Sep 2004 07:51:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBuAT-0003vF-5O; Mon, 27 Sep 2004 07:59:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBu0Q-00051U-K6; Mon, 27 Sep 2004 07:49:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBtwG-0004ho-9S for simple@megatron.ietf.org; Mon, 27 Sep 2004 07:45:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21723 for ; Mon, 27 Sep 2004 07:45:02 -0400 (EDT) Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBu3r-0003nh-5B for simple@ietf.org; Mon, 27 Sep 2004 07:52:56 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i8RBi70L026386; Mon, 27 Sep 2004 13:44:07 +0200 Received: from bruc100e.sbs.be (bruc100e.sbs.be [193.210.175.22]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i8RBi6Mn026772; Mon, 27 Sep 2004 13:44:07 +0200 Received: by bruc100e.sbs.be with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Sep 2004 13:43:17 +0200 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F1958B57EC@hrtades7.atea.be> From: Helsen Frank To: "'Jonathan Rosenberg'" Subject: RE: [Simple] Extend UA Capabiity Extension to PIDF Date: Mon, 27 Sep 2004 13:44:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: Paul Kyzivat , "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 This is indeed what I had in mind. Thanks for the clarification. And I agree that this is not presence information. The approach in RFC3840 where the device capabilities are transported in the REGISTER seems the correct solution. Better then having it in a NOTIFY. However, RFC3840 does not create the option to specify the device. One would not have to think about what device information a provider/PS/Application would like to have. Just specify which device it is and it is up to him to get the required information (using device profiles). Regards, Frank Frank Helsen - MPM/IMC System Engineer Mail: frank.helsen@siemens.com Tel:+32 14 252573 Mobile: +32 494 692959 Siemens HRT IC MN D D1 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: vrijdag 24 september 2004 17:48 To: Paul Kyzivat Cc: Helsen Frank; 'simple@ietf.org' Subject: Re: [Simple] Extend UA Capabiity Extension to PIDF My guess is that Helsen is looking at something equivalent to the UAProf functions in WAP, which allow a client to push fairly complicated information about itself, such as screen size and JVM. I don't think this is "presence" in the sense that much of this information is probably not useful to watchers. However, it does represent valid device information and could conceivably appear there. We do have a specification, RFC 3840, which allows a client to declare its capabilities to the server. That specification does not dictate how this information is used. One usage is caller preferences, RFC 3841, which allows for capability-based called routing. However, I think Helsen has in mind a usage where the provider/domain owner simply wants to look at this profile data for some reason, and that is certainly possible. We have only a very limited set of capabilities declare right now, a much, much, much smaller subset of what is in UAProf. -Jonathan R. Paul Kyzivat wrote: > Helsen, > > I don't understand your terminology very well, or what you are trying to > achieve. > > By 'client' I guess you mean a device addressed by a contact in a tuple > of the presence document, rather than a subscriber to presence. Is that > right? > > I don't know precisely what role you have in mind for 'operator'. Is it > the operator of the presence server itself? Or is it something that is a > client of the PS. What is it doing that requires it to know this > information? > > In general the device will probably be publishing its own presence > status to the presence server. If so the extension you suggest would > simply cause it to push this invariant information over and over. > > This kind of info can already be polled using OPTIONS. Why isn't that > enough? > > Paul > > Helsen Frank wrote: > >> Hello, >> >> >> At this moment, draft-ietf-simple-prescaps-ext-01 does not provide a >> way to indicate to the server which client the user uses. I can >> imagine that an operator has specific client capabilities he would >> like to know (e.g. java virtual machine version, screen size). When >> including this client information, the server could retrieve the >> client capabilities from his e.g. his DB. With this extension, the >> operator has control over the client information and is not dependend >> on the information the client provides to him. >> Next example shows a possible extension >> >> >> Siemens >> CX65 >> 2.103564 >> >> >> Regards, >> >> Frank >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 27 10:06:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00746; Mon, 27 Sep 2004 10:06:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBwHE-0006cP-PQ; Mon, 27 Sep 2004 10:14:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBw8P-0005HE-Pa; Mon, 27 Sep 2004 10:05:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBw7S-0004yF-4k for simple@megatron.ietf.org; Mon, 27 Sep 2004 10:04:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00555 for ; Mon, 27 Sep 2004 10:04:43 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBwF1-0006ZG-T8 for simple@ietf.org; Mon, 27 Sep 2004 10:12:39 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 27 Sep 2004 10:21:15 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8RE46c1020504; Mon, 27 Sep 2004 10:04:08 -0400 (EDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALV82269; Mon, 27 Sep 2004 10:04:06 -0400 (EDT) Message-ID: <41581DD5.9040909@cisco.com> Date: Mon, 27 Sep 2004 10:04:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Chunking References: <5816828233DEFA41807A6CFDFDF2343C08B64B@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org]On Behalf >>Of ext Paul Kyzivat >>Sent: 24.September.2004 19:20 >>To: 'simple@ietf.org' >>Subject: [Simple] Review of draft-ietf-simple-message-sessions-08 - >>Chunking >> >> >>Out approach to chunking has evolved thru the versions, and >>the document >>doesn't seem wholely clear and consistent about what we have >>arrived at. >>In fact, I am not entirely certain I know fully what we have decided, >>and I can't figure it out for certain from the document. I >>would propose >>specific wording changes, but first I want to get clarification about >>how we think it should now work. >> >>Based on scattered information in the doc, and reading between the >>lines, and factoring in stuff from conversations along the way, I >>*think* the following is intended: >> >>- only SEND messages are chunkable >> >>- there are two kinds of chunks: interrruptible and uninterrupible. >> >>- a chunk is uninterruptible if it has a Byte-Range header with a >> numeric range-end. >> >>- other chunks are interruptible. (No Byte-Range, or a Byte-Range >> with a range-end of "*".) >> >>- uninterruptible chunks MUST NOT have a range-end greater than 2048. >> >>- chunks other than the last SHOULD (or MUST?) have a body ('data' >> in the syntax) of length exactly 2048. If SHOULD, what is a >> valid reason to violate? >> >>- responses never have bodies at all. Requests other than SEND >> may have a body but are unchunkable. The presence of a Byte-Range >> in a request other than SEND says nothing about the body of that >> request. (In REPORT it refers to the SEND being reported on. >> See separate thread on Byte-Range.) This at best seems irregular >> and weird. >> >>Section 6.3.1 says: "it is possible the body is shorter than the >>range-end field indicates. This can occur if the sender interrupted a >>SEND request unexpectedly." Based on what I have interpretted above, >>this is no longer possible. (To be interrupted it must have had a >>range-end of "*".) > > > I think it is still possible, but it means that it was an abnormal behaviour. Perhaps we should include some text discussing a recovery mechanism for this case. It is abnormal in the sense that it can only arise if there is a violation of the specification. Normally we don't specify corrective action in those cases. If there is reason we can recommend a recovery action (it is pretty obvious), but should at least note that this is recovery from incorrect sender behavior. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 27 10:19:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02185; Mon, 27 Sep 2004 10:19:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBwTn-0006rt-Gq; Mon, 27 Sep 2004 10:27:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBwKv-0002c3-W8; Mon, 27 Sep 2004 10:18:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBwF0-0001Fc-T9 for simple@megatron.ietf.org; Mon, 27 Sep 2004 10:12:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01232 for ; Mon, 27 Sep 2004 10:12:32 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBwMc-0006hS-O6 for simple@ietf.org; Mon, 27 Sep 2004 10:20:28 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 27 Sep 2004 07:12:58 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i8REBu9Q025893; Mon, 27 Sep 2004 07:11:59 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALV82976; Mon, 27 Sep 2004 10:11:56 -0400 (EDT) Message-ID: <41581FAC.3070305@cisco.com> Date: Mon, 27 Sep 2004 10:11:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - max-size References: <5816828233DEFA41807A6CFDFDF2343C08B64F@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > I believe it applies to a message (spread across 1 to n SENDS requests, i.e. chunks). I am inclined to agree. That means that recipients should be prepared to receive up to 2k bodies with any other request that is permitted to contain a body. (In this spec that is only REPORT.) I think we just need to make this clear. It wasn't entirely clear to me from reading the existing text. Paul > Hisham > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org]On Behalf >>Of ext Paul Kyzivat >>Sent: 24.September.2004 19:21 >>To: simple@ietf.org >>Subject: [Simple] Review of draft-ietf-simple-message-sessions-08 - >>max-size >> >> >>Section 7.1 says: "An endpoint MAY indicate the maximim size message >>they wish to receive using the max-size a-line attribute". >> >>Does this apply only to a *message* - namely the content of a SEND >>request? Or does this apply to any and all requests (including future >>extensions) that have content? >> >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 27 10:51:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05107; Mon, 27 Sep 2004 10:51:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBwxy-0007Us-9Y; Mon, 27 Sep 2004 10:59:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBweC-0008J2-KJ; Mon, 27 Sep 2004 10:38:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBwcb-0007tq-KW for simple@megatron.ietf.org; Mon, 27 Sep 2004 10:36:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04025 for ; Mon, 27 Sep 2004 10:36:55 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBwkD-0007Be-Ud for simple@ietf.org; Mon, 27 Sep 2004 10:44:51 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8REY9g26550; Mon, 27 Sep 2004 17:34:09 +0300 (EET DST) X-Scanned: Mon, 27 Sep 2004 17:34:02 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i8REY2Zh005473; Mon, 27 Sep 2004 17:34:02 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00eXgrOq; Mon, 27 Sep 2004 17:33:59 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8REXnS01235; Mon, 27 Sep 2004 17:33:49 +0300 (EET DST) Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 27 Sep 2004 17:33:46 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 27 Sep 2004 17:33:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Review of draft-ietf-simple-message-sessions-08 - Chunking Date: Mon, 27 Sep 2004 17:33:45 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B656@esebe056.ntc.nokia.com> Thread-Topic: [Simple] Review of draft-ietf-simple-message-sessions-08 - Chunking Thread-Index: AcSkmyDEaR7O1xrSSPSzN5B35PHK2QAA4rHw To: X-OriginalArrivalTime: 27 Sep 2004 14:33:46.0020 (UTC) FILETIME=[FED24E40:01C4A49E] X-Spam-Score: 0.3 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 27.September.2004 17:04 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Review of=20 > draft-ietf-simple-message-sessions-08 - > Chunking >=20 >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: > >=20 > >>-----Original Message----- > >>From: simple-bounces@ietf.org=20 > >>[mailto:simple-bounces@ietf.org]On Behalf > >>Of ext Paul Kyzivat > >>Sent: 24.September.2004 19:20 > >>To: 'simple@ietf.org' > >>Subject: [Simple] Review of draft-ietf-simple-message-sessions-08 - > >>Chunking > >> > >> > >>Out approach to chunking has evolved thru the versions, and=20 > >>the document > >>doesn't seem wholely clear and consistent about what we have=20 > >>arrived at. > >>In fact, I am not entirely certain I know fully what we=20 > have decided, > >>and I can't figure it out for certain from the document. I=20 > >>would propose > >>specific wording changes, but first I want to get=20 > clarification about > >>how we think it should now work. > >> > >>Based on scattered information in the doc, and reading between the > >>lines, and factoring in stuff from conversations along the way, I > >>*think* the following is intended: > >> > >>- only SEND messages are chunkable > >> > >>- there are two kinds of chunks: interrruptible and uninterrupible. > >> > >>- a chunk is uninterruptible if it has a Byte-Range header with a > >> numeric range-end. > >> > >>- other chunks are interruptible. (No Byte-Range, or a Byte-Range > >> with a range-end of "*".) > >> > >>- uninterruptible chunks MUST NOT have a range-end greater=20 > than 2048. > >> > >>- chunks other than the last SHOULD (or MUST?) have a body ('data' > >> in the syntax) of length exactly 2048. If SHOULD, what is a > >> valid reason to violate? > >> > >>- responses never have bodies at all. Requests other than SEND > >> may have a body but are unchunkable. The presence of a=20 > Byte-Range > >> in a request other than SEND says nothing about the body of that > >> request. (In REPORT it refers to the SEND being reported on. > >> See separate thread on Byte-Range.) This at best seems irregular > >> and weird. > >> > >>Section 6.3.1 says: "it is possible the body is shorter than the > >>range-end field indicates. This can occur if the sender=20 > interrupted a > >>SEND request unexpectedly." Based on what I have interpretted above, > >>this is no longer possible. (To be interrupted it must have had a > >>range-end of "*".) > >=20 > >=20 > > I think it is still possible, but it means that it was an=20 > abnormal behaviour. Perhaps we should include some text=20 > discussing a recovery mechanism for this case. >=20 > It is abnormal in the sense that it can only arise if there is a=20 > violation of the specification. Normally we don't specify corrective=20 > action in those cases. No, I meant device or user behaviour that causes the sending to be = immediately aborted. Nothing to do with protocol violation. (eg: abnorla = termination of the application). /Hisham >=20 > If there is reason we can recommend a recovery action (it is pretty=20 > obvious), but should at least note that this is recovery from=20 > incorrect=20 > sender behavior. >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 27 11:52:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09198; Mon, 27 Sep 2004 11:52:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBxux-00008F-4z; Mon, 27 Sep 2004 11:59:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBxli-0003DU-7c; Mon, 27 Sep 2004 11:50:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBxd2-0000Hc-Vw for simple@megatron.ietf.org; Mon, 27 Sep 2004 11:41:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08505 for ; Mon, 27 Sep 2004 11:41:26 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBxkh-0008OQ-1M for simple@ietf.org; Mon, 27 Sep 2004 11:49:23 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 27 Sep 2004 08:41:15 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8RFeslr007629; Mon, 27 Sep 2004 08:40:55 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALV91837; Mon, 27 Sep 2004 11:40:53 -0400 (EDT) Message-ID: <41583485.1010209@cisco.com> Date: Mon, 27 Sep 2004 11:40:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Chunking References: <5816828233DEFA41807A6CFDFDF2343C08B656@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>>>Section 6.3.1 says: "it is possible the body is shorter than the >>>>range-end field indicates. This can occur if the sender >>> >>interrupted a >> >>>>SEND request unexpectedly." Based on what I have interpretted above, >>>>this is no longer possible. (To be interrupted it must have had a >>>>range-end of "*".) >>> >>> >>>I think it is still possible, but it means that it was an >> >>abnormal behaviour. Perhaps we should include some text >>discussing a recovery mechanism for this case. >> >>It is abnormal in the sense that it can only arise if there is a >>violation of the specification. Normally we don't specify corrective >>action in those cases. > > > No, I meant device or user behaviour that causes the sending to be immediately aborted. Nothing to do with protocol violation. (eg: abnorla termination of the application). As best I can tell, we are saying that you must decide, when beginning to send, whether to use an interruptible chunk, or an uninterruptible chunk. If you use an uninterruptible chunk you specify the range-end as a number and include that many bytes of body. If you choose an interruptible chunk, you use "*" for range-end and then you put as much body as you like. An application that chooses to use an uninterruptible chunk, and then fails to include the full number of bytes for it has violated the protocol. Effectively, an application should only use an uninterruptible chunk if it already has all the bytes in hand and ready to send. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Sep 27 12:28:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10949; Mon, 27 Sep 2004 12:28:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CByUE-0000ik-5u; Mon, 27 Sep 2004 12:36:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CByEf-0002uy-OQ; Mon, 27 Sep 2004 12:20:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBxzf-0007Dq-K4 for simple@megatron.ietf.org; Mon, 27 Sep 2004 12:04:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09948 for ; Mon, 27 Sep 2004 12:04:48 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBy7H-0000Mu-Hs for simple@ietf.org; Mon, 27 Sep 2004 12:12:46 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0I4P00H31J81LT@dns1.cselt.it> for simple@ietf.org; Mon, 27 Sep 2004 18:02:26 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.0); Mon, 27 Sep 2004 18:06:02 +0200 Date: Mon, 27 Sep 2004 18:04:14 +0200 From: Goix Walter Subject: RE: [Simple] Extend UA Capabiity Extension to PIDF To: Helsen Frank , Jonathan Rosenberg Message-id: <91C9464F6AFC0647A2D8069E25DBF4962FFB3D@EXC01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Simple] Extend UA Capabiity Extension to PIDF Thread-Index: AcSkiHxDmDmiiy4FQKCtFITH3cxJJQAIgxxw content-class: urn:content-classes:message X-OriginalArrivalTime: 27 Sep 2004 16:06:02.0640 (UTC) FILETIME=[E2E77900:01C4A4AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: Paul Kyzivat , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable I also agree that UAProf-type of information should not be carried along with presence information. I would rather prefer some kind of Profile: header in SIP requests that points to an OMA-like UAProf URL which also describes SIP caps in a more complete way than RFC3840 does (I don't think that RFC has been thought to define such info) Laurent-Walter Goix Telecom Italia - TILAB Service and Platform Innovation - Service Control Platforms > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Helsen Frank > Sent: Monday, September 27, 2004 1:44 PM > To: 'Jonathan Rosenberg' > Cc: Paul Kyzivat; 'simple@ietf.org' > Subject: RE: [Simple] Extend UA Capabiity Extension to PIDF >=20 >=20 > This is indeed what I had in mind. Thanks for the=20 > clarification. And I agree that this is not presence=20 > information. The approach in RFC3840 where the device=20 > capabilities are transported in the REGISTER seems the=20 > correct solution. Better then having it in a NOTIFY. =20 > However, RFC3840 does not create the option to specify the=20 > device. One would not have to think about what device=20 > information a provider/PS/Application would like to have. =20 > Just specify which device it is and it is up to him to get=20 > the required information (using device profiles). >=20 > Regards, >=20 > Frank >=20 > Frank Helsen - MPM/IMC System Engineer > Mail: frank.helsen@siemens.com > Tel:+32 14 252573 > Mobile: +32 494 692959 > Siemens HRT IC MN D D1 >=20 >=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 > Sent: vrijdag 24 september 2004 17:48 > To: Paul Kyzivat > Cc: Helsen Frank; 'simple@ietf.org' > Subject: Re: [Simple] Extend UA Capabiity Extension to PIDF >=20 >=20 > My guess is that Helsen is looking at something equivalent to=20 > the UAProf=20 > functions in WAP, which allow a client to push fairly complicated=20 > information about itself, such as screen size and JVM. I don't think=20 > this is "presence" in the sense that much of this information is=20 > probably not useful to watchers. However, it does represent=20 > valid device=20 > information and could conceivably appear there. >=20 > We do have a specification, RFC 3840, which allows a client=20 > to declare=20 > its capabilities to the server. That specification does not=20 > dictate how=20 > this information is used. One usage is caller preferences, RFC 3841,=20 > which allows for capability-based called routing. However, I think=20 > Helsen has in mind a usage where the provider/domain owner=20 > simply wants=20 > to look at this profile data for some reason, and that is certainly=20 > possible. >=20 > We have only a very limited set of capabilities declare right now, a=20 > much, much, much smaller subset of what is in UAProf. >=20 > -Jonathan R. Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 28 08:09:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16337; Tue, 28 Sep 2004 08:09:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCGvk-000870-BC; Tue, 28 Sep 2004 08:18:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCGkv-0002yg-9r; Tue, 28 Sep 2004 08:06:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCGeG-00029q-E5 for simple@megatron.ietf.org; Tue, 28 Sep 2004 08:00:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15714 for ; Tue, 28 Sep 2004 07:59:59 -0400 (EDT) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCGm4-0007uw-E4 for simple@ietf.org; Tue, 28 Sep 2004 08:08:05 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8SBxL119979; Tue, 28 Sep 2004 14:59:21 +0300 (EET DST) X-Scanned: Tue, 28 Sep 2004 14:59:02 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i8SBx2Lw013491; Tue, 28 Sep 2004 14:59:02 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00QHagGi; Tue, 28 Sep 2004 14:58:59 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8SBwxS17509; Tue, 28 Sep 2004 14:58:59 +0300 (EET DST) Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 28 Sep 2004 14:58:58 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe024.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 28 Sep 2004 14:58:57 +0300 Received: ESEBE054.NOE.Nokia.com 172.21.143.44 from 172.21.148.134 172.21.148.134 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost by ESEBE054.NOE.Nokia.com; 28 Sep 2004 14:58:57 +0300 Subject: RE: [Simple] Extend UA Capabiity Extension to PIDF From: Aki Niemi To: ext Goix Walter In-Reply-To: <91C9464F6AFC0647A2D8069E25DBF4962FFB3D@EXC01B.cselt.it> References: <91C9464F6AFC0647A2D8069E25DBF4962FFB3D@EXC01B.cselt.it> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1096372737.25447.30.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 28 Sep 2004 14:58:57 +0300 X-OriginalArrivalTime: 28 Sep 2004 11:58:57.0917 (UTC) FILETIME=[891802D0:01C4A552] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , Jonathan Rosenberg , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit On Mon, 2004-09-27 at 19:04, ext Goix Walter wrote: > I also agree that UAProf-type of information should not be carried along > with presence information. I would rather prefer some kind of Profile: > header in SIP requests that points to an OMA-like UAProf URL which also > describes SIP caps in a more complete way than RFC3840 does (I don't > think that RFC has been thought to define such info) How about using the User-Agent header field? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 28 08:40:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18288; Tue, 28 Sep 2004 08:40:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCHPc-0000JC-Jc; Tue, 28 Sep 2004 08:48:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCH8t-0006us-6j; Tue, 28 Sep 2004 08:31:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCH4M-0006JQ-Oh for simple@megatron.ietf.org; Tue, 28 Sep 2004 08:26:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17570 for ; Tue, 28 Sep 2004 08:26:57 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCHCB-0008VE-Cl for simple@ietf.org; Tue, 28 Sep 2004 08:35:04 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0I4R00H1Q3SXMV@dns1.cselt.it> for simple@ietf.org; Tue, 28 Sep 2004 14:24:33 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.0); Tue, 28 Sep 2004 14:28:11 +0200 Date: Tue, 28 Sep 2004 14:26:23 +0200 From: Goix Walter Subject: RE: [Simple] Extend UA Capabiity Extension to PIDF To: Aki Niemi , ext Goix Walter Message-id: <91C9464F6AFC0647A2D8069E25DBF4962FFB4B@EXC01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Simple] Extend UA Capabiity Extension to PIDF Thread-Index: AcSlUrwNB2C7p10MRgK9RzV9tOarzgAAdLGw content-class: urn:content-classes:message X-OriginalArrivalTime: 28 Sep 2004 12:28:11.0453 (UTC) FILETIME=[9E485ED0:01C4A556] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: Paul Kyzivat , Jonathan Rosenberg , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable I'm not sure I get your point, whether you propose to use the User Agent: header as is (1), "modified" for transporting a UAProf URI (2), or if you see some external mechanism that knows the matching between User-Agent: header value and UAProf-type of capabilities related to SIP (3)... If (1), I personally see the User-Agent: header as something related to SIP UA "binary" module name and version (for vendor's use only, or for opaque upgrade from an operator when the version is considered as obsolete). I think the info here is also related to device caps (screen size, color for max img size when sending an image or things like that). The User-Agent may not provide that info unless (3), but then you may add complexity in your network if you need to provision this matching (version/UAProf) on many NEs. The matching itself may also be tricky in some situations. IMHO, I think having this info provided directly by the UA itself could be helpful and simplier for Application Servers or proxies to process a request based on such info. walter =20 > -----Original Message----- > From: Aki Niemi [mailto:aki.niemi@nokia.com]=20 > Sent: Tuesday, September 28, 2004 1:59 PM > To: ext Goix Walter > Cc: Helsen Frank; Jonathan Rosenberg; Paul Kyzivat; SIMPLE WG > Subject: RE: [Simple] Extend UA Capabiity Extension to PIDF >=20 >=20 > On Mon, 2004-09-27 at 19:04, ext Goix Walter wrote: > > I also agree that UAProf-type of information should not be carried=20 > > along with presence information. I would rather prefer some kind of=20 > > Profile: header in SIP requests that points to an OMA-like=20 > UAProf URL=20 > > which also describes SIP caps in a more complete way than=20 > RFC3840 does=20 > > (I don't think that RFC has been thought to define such info) >=20 > How about using the User-Agent header field? >=20 > Cheers, > Aki >=20 >=20 >=20 >=20 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 28 10:06:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23638; Tue, 28 Sep 2004 10:06:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCIkJ-0001zy-RN; Tue, 28 Sep 2004 10:14:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCIWG-0008GC-Fj; Tue, 28 Sep 2004 09:59:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCIUW-0007xF-Dn for simple@megatron.ietf.org; Tue, 28 Sep 2004 09:58:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23251 for ; Tue, 28 Sep 2004 09:58:02 -0400 (EDT) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCIcM-0001rt-CT for simple@ietf.org; Tue, 28 Sep 2004 10:06:10 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8SDtR604623; Tue, 28 Sep 2004 16:55:27 +0300 (EET DST) X-Scanned: Tue, 28 Sep 2004 16:54:59 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i8SDsxV3020213; Tue, 28 Sep 2004 16:54:59 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 001ZbMdZ; Tue, 28 Sep 2004 16:54:56 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8SDstY29261; Tue, 28 Sep 2004 16:54:55 +0300 (EET DST) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 28 Sep 2004 16:54:52 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 28 Sep 2004 16:54:52 +0300 Received: ESEBE054.NOE.Nokia.com 172.21.143.44 from 172.21.148.134 172.21.148.134 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost by ESEBE054.NOE.Nokia.com; 28 Sep 2004 16:54:52 +0300 Subject: RE: [Simple] Extend UA Capabiity Extension to PIDF From: Aki Niemi To: ext Goix Walter In-Reply-To: <91C9464F6AFC0647A2D8069E25DBF4962FFB4B@EXC01B.cselt.it> References: <91C9464F6AFC0647A2D8069E25DBF4962FFB4B@EXC01B.cselt.it> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1096379691.25447.184.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 28 Sep 2004 16:54:52 +0300 X-OriginalArrivalTime: 28 Sep 2004 13:54:52.0666 (UTC) FILETIME=[BA727DA0:01C4A562] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , Jonathan Rosenberg , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit On Tue, 2004-09-28 at 15:26, ext Goix Walter wrote: > I'm not sure I get your point, whether you propose to use the User > Agent: header as is (1), "modified" for transporting a UAProf URI (2), > or if you see some external mechanism that knows the matching between > User-Agent: header value and UAProf-type of capabilities related to SIP > (3)... > > If (1), I personally see the User-Agent: header as something related to > SIP UA "binary" module name and version (for vendor's use only, or for > opaque upgrade from an operator when the version is considered as > obsolete). I think the info here is also related to device caps (screen > size, color for max img size when sending an image or things like that). > The User-Agent may not provide that info unless (3), but then you may > add complexity in your network if you need to provision this matching > (version/UAProf) on many NEs. The matching itself may also be tricky in > some situations. Which I guess leaves you with option (2). There doesn't seem to be much in the way of putting information there that goes beyond the name and version of the binary. In web browsers this information many times contains OS, and even CPU information. Having said that though, if the intention originally was to have CC/PP in SIP, then it would've been best to say so to begin with... > IMHO, I think having this info provided directly by the UA itself could > be helpful and simplier for Application Servers or proxies to process a > request based on such info. I agree, but whether you need something beyond callee-caps and User-Agent is then another question. Also, I think some information actually does belong in presence. For example, it might be worthwhile expressing maximum attachment size in a mailto tuple. Depends what you would like to do, and who the primary consumer of this information would be (e2e vs. e2m). Cheers, Aki > walter > > > -----Original Message----- > > From: Aki Niemi [mailto:aki.niemi@nokia.com] > > Sent: Tuesday, September 28, 2004 1:59 PM > > To: ext Goix Walter > > Cc: Helsen Frank; Jonathan Rosenberg; Paul Kyzivat; SIMPLE WG > > Subject: RE: [Simple] Extend UA Capabiity Extension to PIDF > > > > > > On Mon, 2004-09-27 at 19:04, ext Goix Walter wrote: > > > I also agree that UAProf-type of information should not be carried > > > along with presence information. I would rather prefer some kind of > > > Profile: header in SIP requests that points to an OMA-like > > UAProf URL > > > which also describes SIP caps in a more complete way than > > RFC3840 does > > > (I don't think that RFC has been thought to define such info) > > > > How about using the User-Agent header field? > > > > Cheers, > > Aki > > > > > > > > > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. > > ==================================================================== > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > ==================================================================== _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 28 10:32:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26223; Tue, 28 Sep 2004 10:32:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCJA7-0002TW-76; Tue, 28 Sep 2004 10:41:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCJ0K-0001B4-Uo; Tue, 28 Sep 2004 10:30:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCIva-0008PU-0X for simple@megatron.ietf.org; Tue, 28 Sep 2004 10:26:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25711 for ; Tue, 28 Sep 2004 10:25:59 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCJ3M-0002M2-Qr for simple@ietf.org; Tue, 28 Sep 2004 10:34:08 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0I4R00M0C9BARZ@dns1.cselt.it> for simple@ietf.org; Tue, 28 Sep 2004 16:23:34 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.0); Tue, 28 Sep 2004 16:27:11 +0200 Date: Tue, 28 Sep 2004 16:25:16 +0200 From: Goix Walter Subject: RE: [Simple] Extend UA Capabiity Extension to PIDF To: Aki Niemi , ext Goix Walter Message-id: <91C9464F6AFC0647A2D8069E25DBF4962FFB50@EXC01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Simple] Extend UA Capabiity Extension to PIDF Thread-Index: AcSlYzv7M0cFeCd/St6zOVsy2ks4tQAAKN+w content-class: urn:content-classes:message X-OriginalArrivalTime: 28 Sep 2004 14:27:11.0375 (UTC) FILETIME=[3E0201F0:01C4A567] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: Paul Kyzivat , Jonathan Rosenberg , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable >=20 > Which I guess leaves you with option (2). There doesn't seem=20 > to be much in the way of putting information there that goes=20 > beyond the name and version of the binary. In web browsers=20 > this information many times contains OS, and even CPU information. >=20 > Having said that though, if the intention originally was to=20 > have CC/PP in SIP, then it would've been best to say so to=20 > begin with... I agree that option (2) is not the right way to go.=20 Going UAProf, which may be useful for many services, implies to put CC/PP in SIP as you said (maybe an URL into an header in some cases, or the same URL as a XML tag in presence information), and also to extend CC/PP with SIP-related info >=20 > > IMHO, I think having this info provided directly by the UA itself=20 > > could be helpful and simplier for Application Servers or proxies to=20 > > process a request based on such info. >=20 > I agree, but whether you need something beyond callee-caps=20 > and User-Agent is then another question.=20 >=20 > Also, I think some information actually does belong in=20 > presence. For example, it might be worthwhile expressing=20 > maximum attachment size in a mailto tuple. Depends what you=20 > would like to do, and who the primary consumer of this=20 > information would be (e2e vs. e2m). I do believe as well there is a need to put these kind of caps into presence info. CC/PP is not the only option for this but could be a rich, standard way to provision such info from the UA to the server, for example through an URL into a PUBLISH header, which could also be reused in other methods. Once they get this info, presence servers can decide whether and how to send this info (or part of it) to watchers, by sending an HTTL URL of the profile into PIDF doc (this woul require watchers to have an HTTP stack) or extracting info and putting it into some PIDF extension (like you said "max attachment size" for example, or supported content-types based on the SIP method or type of session, etc. that are not supported by callee-caps). In this case, why not reuse CC/PP schema and if not enough simply extend it? CC/PP already has a lot of info that may be useful for watchers. walter=20 >=20 > Cheers, > Aki Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 28 17:14:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24715; Tue, 28 Sep 2004 17:14:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCPQQ-00035v-8o; Tue, 28 Sep 2004 17:22:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCPB3-0000ps-2Y; Tue, 28 Sep 2004 17:06:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCP3j-0007OA-LM for simple@megatron.ietf.org; Tue, 28 Sep 2004 16:58:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23981 for ; Tue, 28 Sep 2004 16:58:49 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCPBd-0002pL-K8 for simple@ietf.org; Tue, 28 Sep 2004 17:07:01 -0400 Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8SKwgpl012693 for ; Tue, 28 Sep 2004 16:58:42 -0400 (EDT) Message-ID: <4159D06C.7020308@dynamicsoft.com> Date: Tue, 28 Sep 2004 16:58:20 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Subject: [Simple] updated presence data model draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Folks, I've just submitted an updated presence data model draft. Until it appears in the archives, you can pick it up as: http://www.jdrosen.net/papers/draft-ietf-simple-presence-data-model-00.txt There are a number of changes since the last version, which I will send in a separate note. The most important one to note is that, instead of using to encode device and person information (person is the new term for user data, like "in a meeting" and "sad"), it is encoded using a separate and element which are defined in the document, including schema. The reason for this is: 1. its backwards compatible with existing pidf implementations, whereas the former approach would have caused problems 2. its the natural way to do this if you were designing the schema from scratch anyway 3. it avoids the need for the "ugliness" of a separate element to tell you what the tuple actually was The drawback is that it will require modification of the partial publication and partial notification drafts. However, as these are still I-D it doesnt seem so troubling, as compared to the more real issues above. This revision doesn't include the latest discussions on tel URI and service identification. Most of the revisions are based on conclusions reached by the design team when we met during IETF. In particular, we believe that there is sufficient agreement on the document that we can go ahead and update rpid, cipid and related spcifications to be in line with the model, and proceed with those documents at this time. There are some open issues in the data model, which I will send out notes on shortly. I don't think any of these gate rpid/cipid from proceeding. Henning has given me source for those documents, and I'll be modifying and submitting updates to those shortly. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 28 17:14:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24747; Tue, 28 Sep 2004 17:14:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCPQn-00036Q-RB; Tue, 28 Sep 2004 17:22:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCPBF-00011C-PZ; Tue, 28 Sep 2004 17:06:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCP5g-0007kb-Hn for simple@megatron.ietf.org; Tue, 28 Sep 2004 17:00:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24035 for ; Tue, 28 Sep 2004 17:00:50 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCPDZ-0002q9-HW for simple@ietf.org; Tue, 28 Sep 2004 17:09:02 -0400 Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8SL0gpl012706 for ; Tue, 28 Sep 2004 17:00:42 -0400 (EDT) Message-ID: <4159D0E5.6010606@dynamicsoft.com> Date: Tue, 28 Sep 2004 17:00:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Subject: [Simple] diffs in presence data model from previous version X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit * Terminology: using "person" to refer to the human-user status (busy, in a meeting, etc.), with presentity representing the combination of person, device and service information * mention that the presentity URI will often be the SIP AOR, and that such equivalence is recommended. * UUID URN for device ID * mention that device IDs are ideally obtained from operating system * clarified the role of characteristics and status information for devices - cannot be used to determine nature of the service. Rather, aids in the selection of service based on what the device is. Clarified that status of a device does not affect status of the service unless it is known otherwise. * cleaned up document to remove references to "what is a tuple", or "this group has had trouble" and other discussions not appropriate in an RFC * clarified that it is not that important to cleanly delineate status and characteristic information. * syntax is now using new and elements, rather than re-using tuple. It was felt that this was likely to be backwards compatible with existing PIDF implementations, whereas the previous approach would not be. It does mean that partial publish and partial notify specs will need to change, but they are not done yet. * clarified that a PUA can "represent" a service, device or person, but is usually a service, and the discussion focuses on that. * changed definition of service, presentity and device views, based on the fact that a presence document has to contain at least one service tuple * updated references and examples * removed plan-of-action section * clarified that privacy filtering can run at the request of the presentity or other parties * added dsicussion of deciding to combine a set of services together because they provided contacts that are gruus under the same aor * added a lot of text on overriding published information and on time-based conflict resolution in presence servers * removed example of helpdesk application as a case where the r-uri of the publish is not the same as the entity field in the presence document, since its confusing and not a good use case. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 28 17:23:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25096; Tue, 28 Sep 2004 17:23:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCPZM-0003Eu-ML; Tue, 28 Sep 2004 17:31:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCPIJ-0002zJ-UD; Tue, 28 Sep 2004 17:13:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCPAs-0000pQ-5y for simple@megatron.ietf.org; Tue, 28 Sep 2004 17:06:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24232 for ; Tue, 28 Sep 2004 17:06:11 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCPIm-0002vC-71 for simple@ietf.org; Tue, 28 Sep 2004 17:14:24 -0400 Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8SL65pl012724 for ; Tue, 28 Sep 2004 17:06:05 -0400 (EDT) Message-ID: <4159D228.5040905@dynamicsoft.com> Date: Tue, 28 Sep 2004 17:05:44 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Subject: [Simple] Pres Data Model Open Issue #1: in-person communications X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Currently, there is no easy way to incorporate the notion of "in person" or "written/postal" communications as services represented in the data model. The reason is that there is no URI scheme for them, and no attributes that can be used to define them. The issue is, what to do about this? My proposal is to punt the issue in this document. State that it is expected that future specifications will address how to represent these. To actually solve the problem, I think the right approach is to define a URN scheme along the lines of "urn:inperson" to represent an in-person communications scheme. For postal communications, I think you want a URN that includes the postal address, something like urn:postal:sname=Lanidex%20Plaza-snumber=600-state=NJ-city=Parsippany-zip=07054 or something like that. Thats probably a fairly hard problem to solve, and I think even less important for us to tackle. However, we can defer working on either of those in earnest for a bit, until our basic work is done. Comments? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 28 17:27:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25270; Tue, 28 Sep 2004 17:27:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCPd0-0003In-JJ; Tue, 28 Sep 2004 17:35:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCPNp-0003pB-5Q; Tue, 28 Sep 2004 17:19:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCPFG-0002MC-AE for simple@megatron.ietf.org; Tue, 28 Sep 2004 17:10:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24500 for ; Tue, 28 Sep 2004 17:10:43 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCPNA-00030S-CY for simple@ietf.org; Tue, 28 Sep 2004 17:18:56 -0400 Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8SLAbpl012742 for ; Tue, 28 Sep 2004 17:10:37 -0400 (EDT) Message-ID: <4159D337.3070101@dynamicsoft.com> Date: Tue, 28 Sep 2004 17:10:15 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [Simple] Pres Data Model Open Issue #2: fate of roach-simple-service-features? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Currently, draft-roach-simple-service-features is an expired I-D. The approach it describes, of using service attributes rather than an enumeration of services, has been incorporated into the model already. However, the draft has useful explanatory text and examples. Should this draft proceed separately or should it be folded into the data model draft? I would propose that the discussion of the problems with service enumeration be integrated into the data model, along with the benefits of service deduction. However, the examples of describing various services should probably proceed as a BCP in a separate document. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 28 17:36:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25628; Tue, 28 Sep 2004 17:36:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCPls-0003QG-11; Tue, 28 Sep 2004 17:44:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCPYG-0005Ht-RF; Tue, 28 Sep 2004 17:30:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCPNx-0003qS-Cy for simple@megatron.ietf.org; Tue, 28 Sep 2004 17:19:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24992 for ; Tue, 28 Sep 2004 17:19:42 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCPVr-0003BY-H7 for simple@ietf.org; Tue, 28 Sep 2004 17:27:55 -0400 Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8SLJapl012773 for ; Tue, 28 Sep 2004 17:19:36 -0400 (EDT) Message-ID: <4159D54F.5060700@dynamicsoft.com> Date: Tue, 28 Sep 2004 17:19:11 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Subject: [Simple] Pres Data Model Open Issue #3, UUID URN or something else X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit One of the things the design team spent a lot of time discussing was what a device ID looked like. Our conclusion, as documented in the I-D, is that its a URN. We can't lock down the specific type of URN, but for things where MAC address is a useful unique device identifier, the UUID URN (as it makes use of a MAC address) is a good choice. However, upon a more detailed read of the UUID URN specification, I am not sure we can use it. The reason is that the UUID URN spec (http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-03.txt) describes several ways of computing the URN. There are actually four versions. The time-based version uses the host MAC, along with the current time, to generate the UUID. The name-based version doesnt use time, but relies on a unique namespace, such as DNS or URIs, as a seed. MAC address is not a choice. So, the problem is, the UUID form that utilizes the MAC address also includes a time-based component. This serves to provide uniqueness, but makes it useless as a meaningful identifier that other presence sources - like an ethernet switch or 802.11 AP, would be able to provide information about. So, the options as I see them are: 1. use UUID URN anyway, lose the correlation properties we wanted 2. dont specify the URN form at all 3. don't specify the URN form in this document, but work on this problem in downstream specifications I would propose approach (3). In particular, I think the data model should revert to being agnostic on the URN scheme, reference the UUID URN as one possibility, document its problems. We should develop a separate specification that defines guidelines for choosing the URN for various devices in order to get the correlation properties we want. I also think we should take a stab at defining a few URN schemes that would be useful - MAC and ESN in particular. Comments? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 28 17:36:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25658; Tue, 28 Sep 2004 17:36:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCPmU-0003RK-MU; Tue, 28 Sep 2004 17:45:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCPaY-0005aa-KX; Tue, 28 Sep 2004 17:32:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCPQp-0004Dt-Ge for simple@megatron.ietf.org; Tue, 28 Sep 2004 17:22:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25072 for ; Tue, 28 Sep 2004 17:22:40 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCPYi-0003E4-Mj for simple@ietf.org; Tue, 28 Sep 2004 17:30:53 -0400 Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8SLMXpl012785 for ; Tue, 28 Sep 2004 17:22:33 -0400 (EDT) Message-ID: <4159D600.8010201@dynamicsoft.com> Date: Tue, 28 Sep 2004 17:22:08 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: [Simple] Pres Data Model Issue #4, indicating the source of data X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit The data model draft spends a fair bit of time talking about conflicting data, and how a presence server can resolve the conflicts. One of the things it talks about is making use of presence meta-data, and in particular, the source of a piece of presence data, as a tool in deciding how to resolve conflicts. The question is, do we want to do any work in defining ways of identifying the source of the presence information? I am strongly inclined to say "no", and simply leave this as a potential future issue to address. I would modify the data model draft to talk about meta-data, but not say anything about future standardization or any specific specs where such meta-data are defined. Comments? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 28 17:43:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26092; Tue, 28 Sep 2004 17:43:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCPtB-0003Zf-S5; Tue, 28 Sep 2004 17:52:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCPdx-0006f7-0v; Tue, 28 Sep 2004 17:36:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCPYG-0005Hr-K7 for simple@megatron.ietf.org; Tue, 28 Sep 2004 17:30:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25457 for ; Tue, 28 Sep 2004 17:30:21 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCPgA-0003Lb-R5 for simple@ietf.org; Tue, 28 Sep 2004 17:38:35 -0400 Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8SLUFpl012813 for ; Tue, 28 Sep 2004 17:30:15 -0400 (EDT) Message-ID: <4159D7CD.3010600@dynamicsoft.com> Date: Tue, 28 Sep 2004 17:29:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Subject: [Simple] Pres Data Model Open Issue #5: what does idle mean? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit This isn't really an issue with the data model so much as rpid, but its used as an example in the data model. The question is, in the context of the data model, what does mean? Does apply to a person? To a device? To a service? For each case, what does it mean? Does it merely mean, "the likelihood is that attempts to reach this service will result in a no-answer", or is it something more specific, such as "idle indicates that no user input has been provided to this device (service) recently". The first question is to determine its definition, I think. Once you know what it means, you can decide whether it applies to devices, services or person. I'm somewhat on the fence here. One argument is that you want a concise and measurable definition, so that a PUA can concretely say, "this service is idle", and have the recipient of the document know what it means. That would argue for something based on user input. The problem with that definition is that ultimately, the lack of user input is useful because it is an indicator of the real quantity of interest - the likelihood that I'll get a "no answer". So, why not define it as the data we really want. The problem is that you will see vast differences across devices in declaring themselves idle, and thus differing interpretations of what to do when you see it in a document. Feature or bug? You decide. At this moment, I'm inclined to the concrete definition (lack of user input), and have it be associated with the device, not the service. I know others have different opinions. Lets sort this out. [this is the final open issue I am aware of] Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 28 18:47:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00599; Tue, 28 Sep 2004 18:47:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCQt7-0004uc-8l; Tue, 28 Sep 2004 18:56:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCQSj-0000AZ-9s; Tue, 28 Sep 2004 18:28:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCQL8-0005l1-OR for simple@megatron.ietf.org; Tue, 28 Sep 2004 18:20:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28595 for ; Tue, 28 Sep 2004 18:20:51 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCQT3-0004Ag-8e for simple@ietf.org; Tue, 28 Sep 2004 18:29:05 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 28 Sep 2004 15:23:51 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8SMKElx022758; Tue, 28 Sep 2004 15:20:21 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALX13508; Tue, 28 Sep 2004 18:19:16 -0400 (EDT) Message-ID: <4159E364.8030204@cisco.com> Date: Tue, 28 Sep 2004 18:19:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Pres Data Model Open Issue #3, UUID URN or something else References: <4159D54F.5060700@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > One of the things the design team spent a lot of time discussing was > what a device ID looked like. Our conclusion, as documented in the I-D, > is that its a URN. We can't lock down the specific type of URN, but for > things where MAC address is a useful unique device identifier, the UUID > URN (as it makes use of a MAC address) is a good choice. > > However, upon a more detailed read of the UUID URN specification, I am > not sure we can use it. The reason is that the UUID URN spec > (http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-03.txt) > describes several ways of computing the URN. There are actually four > versions. The time-based version uses the host MAC, along with the > current time, to generate the UUID. The name-based version doesnt use > time, but relies on a unique namespace, such as DNS or URIs, as a seed. > MAC address is not a choice. > > So, the problem is, the UUID form that utilizes the MAC address also > includes a time-based component. This serves to provide uniqueness, but > makes it useless as a meaningful identifier that other presence sources > - like an ethernet switch or 802.11 AP, would be able to provide > information about. > > So, the options as I see them are: > > 1. use UUID URN anyway, lose the correlation properties we wanted > 2. dont specify the URN form at all > 3. don't specify the URN form in this document, but work on this problem > in downstream specifications > > I would propose approach (3). In particular, I think the data model > should revert to being agnostic on the URN scheme, reference the UUID > URN as one possibility, document its problems. We should develop a > separate specification that defines guidelines for choosing the URN for > various devices in order to get the correlation properties we want. I > also think we should take a stab at defining a few URN schemes that > would be useful - MAC and ESN in particular. I think it does make sense to leave the particular choice out of this document. I do think the problem with UUID can be dealt with in a couple of ways: - for some kinds of "devices", like softphones and IM clients, it is probably fine as-is. They can typically have multiple instances per device, so they must construct and instance id and save it persistently as part of the instance configuration. - for a dedicated device, like a phone, that can't or doesn't want to use the above technique, a cannonical mac-based uuid can be constructed by using a fixed time (e.g. zero) along with the mac. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 28 20:32:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09059; Tue, 28 Sep 2004 20:32:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCSWN-0007mo-KY; Tue, 28 Sep 2004 20:40:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCS3y-0001qy-Q9; Tue, 28 Sep 2004 20:11:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCRu7-0005vd-8G for simple@megatron.ietf.org; Tue, 28 Sep 2004 20:01:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06704 for ; Tue, 28 Sep 2004 20:01:03 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCS22-0006zA-N2 for simple@ietf.org; Tue, 28 Sep 2004 20:09:19 -0400 Received: from razor.cs.columbia.edu (IDENT:7o9JAJMyKIbheN+ovdB/ExfHcpZQn3pl@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8T011x6024994 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 28 Sep 2004 20:01:01 -0400 (EDT) Received: from [127.0.0.1] (IDENT:JwIRJTns2CAC+r0xb6WbjG2zZi7UM+9P@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8T00uYZ026287; Tue, 28 Sep 2004 20:00:58 -0400 Message-ID: <4159FB36.9090502@cs.columbia.edu> Date: Tue, 28 Sep 2004 20:00:54 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Pres Data Model Open Issue #1: in-person communications References: <4159D228.5040905@dynamicsoft.com> In-Reply-To: <4159D228.5040905@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.9.28.3 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit I agree, although the two examples you give are rather different in their usefulness. In practice, status information for the postal elements is not particularly useful as it doesn't tend to change a lot. Your postal availability is not exactly something subject to OPEN/CLOSED. Plus, the CIPID vcard element already allows to express this. The in-person indication is definitely more useful for coordination. I'd argue you'd actually want a "protocol" indication, not a URN indication, since you've already identified the person. As you said, this can easily be solved by a convention, maybe suitably defined in an April 1 RFC, along with the carrier pigeon URL. Jonathan Rosenberg wrote: > Currently, there is no easy way to incorporate the notion of "in person" > or "written/postal" communications as services represented in the data > model. The reason is that there is no URI scheme for them, and no > attributes that can be used to define them. The issue is, what to do > about this? > > My proposal is to punt the issue in this document. State that it is > expected that future specifications will address how to represent these. > > To actually solve the problem, I think the right approach is to define a > URN scheme along the lines of "urn:inperson" to represent an in-person > communications scheme. For postal communications, I think you want a URN > that includes the postal address, something like > urn:postal:sname=Lanidex%20Plaza-snumber=600-state=NJ-city=Parsippany-zip=07054 > or something like that. Thats probably a fairly hard problem to solve, > and I think even less important for us to tackle. > > However, we can defer working on either of those in earnest for a bit, > until our basic work is done. > > Comments? > > Thanks, > Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Sep 28 20:42:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09667; Tue, 28 Sep 2004 20:42:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCSfy-0007wz-Cc; Tue, 28 Sep 2004 20:50:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCSMm-0006yg-EL; Tue, 28 Sep 2004 20:30:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCS2j-0000eg-Jf for simple@megatron.ietf.org; Tue, 28 Sep 2004 20:10:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07490 for ; Tue, 28 Sep 2004 20:09:59 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCSAf-0007HU-3H for simple@ietf.org; Tue, 28 Sep 2004 20:18:13 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 28 Sep 2004 17:09:31 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 28 Sep 2004 17:09:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Review of draft-ietf-simple-message-sessions-08 -Chunking Date: Tue, 28 Sep 2004 17:09:30 -0700 Message-ID: Thread-Topic: [Simple] Review of draft-ietf-simple-message-sessions-08 -Chunking Thread-Index: AcSkqgi/4wF3R1O8Qi+OokSzix0v5QBDL8Ng From: "Orit Levin" To: "Paul Kyzivat" , X-OriginalArrivalTime: 29 Sep 2004 00:09:32.0223 (UTC) FILETIME=[98604CF0:01C4A5B8] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Sorry for jumping in late. This exact topic was among the issues that I sent to the MSRP authors two weeks ago. I completely agree with Paul's summary below and that the statement in Section 6.3.1 saying "it is possible the body is shorter than the range-end field indicates. This can occur if the sender interrupted a SEND request unexpectedly" must go away. BTW Just to ensure that my understanding is correct. In Paul's summary below the "sender" can be an MSRP relay, is it correct? An MSRP relay MAY convert a uninterruptible chunk into a interruptible chunk, but the opposite is not true. Can we confirm that we have an agreement on the whole issue? Thanks a lot, Orit. > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, September 27, 2004 8:41 AM > To: hisham.khartabil@nokia.com > Cc: simple@ietf.org > Subject: Re: [Simple] Review of=20 > draft-ietf-simple-message-sessions-08 -Chunking >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: > >=20 > >>>>Section 6.3.1 says: "it is possible the body is shorter than the=20 > >>>>range-end field indicates. This can occur if the sender > >>> > >>interrupted a > >> > >>>>SEND request unexpectedly." Based on what I have=20 > interpretted above,=20 > >>>>this is no longer possible. (To be interrupted it must have had a=20 > >>>>range-end of "*".) > >>> > >>> > >>>I think it is still possible, but it means that it was an > >> > >>abnormal behaviour. Perhaps we should include some text=20 > discussing a=20 > >>recovery mechanism for this case. > >> > >>It is abnormal in the sense that it can only arise if there is a=20 > >>violation of the specification. Normally we don't specify=20 > corrective=20 > >>action in those cases. > >=20 > >=20 > > No, I meant device or user behaviour that causes the=20 > sending to be immediately aborted. Nothing to do with=20 > protocol violation. (eg: abnorla termination of the application). >=20 > As best I can tell, we are saying that you must decide, when=20 > beginning to send, whether to use an interruptible chunk, or=20 > an uninterruptible chunk. If you use an uninterruptible chunk=20 > you specify the range-end as a number and include that many=20 > bytes of body. If you choose an interruptible chunk, you use=20 > "*" for range-end and then you put as much body as you like. >=20 > An application that chooses to use an uninterruptible chunk,=20 > and then fails to include the full number of bytes for it has=20 > violated the protocol. >=20 > Effectively, an application should only use an=20 > uninterruptible chunk if it already has all the bytes in hand=20 > and ready to send. >=20 > Paul >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 29 00:30:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24140; Wed, 29 Sep 2004 00:30:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCWFE-0003sG-TC; Wed, 29 Sep 2004 00:39:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCW5c-0003SL-CA; Wed, 29 Sep 2004 00:29:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCW2c-0002WI-IS for simple@megatron.ietf.org; Wed, 29 Sep 2004 00:26:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23845 for ; Wed, 29 Sep 2004 00:26:06 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCWAZ-0003mq-9A for simple@ietf.org; Wed, 29 Sep 2004 00:34:23 -0400 Received: from dynamicsoft.com ([63.113.46.7]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8T4Pvpl014235; Wed, 29 Sep 2004 00:25:58 -0400 (EDT) Message-ID: <415A393F.3050900@dynamicsoft.com> Date: Wed, 29 Sep 2004 00:25:35 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: [Simple] Scope of XCAP PIDF manipulation wrt. Presence Data Model References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Markus, You make a good point about another use case for the pidf manipulation. Based on this, I think the pidf-manipulation draft needs to more carefully outline the use cases. I think it would be good to point out that it is ideal for: (1) manipulating person information, (2) manipulating services that operate in the absence of agents that actively run on behalf of the user (email, for example) In essence, then, the distinction is that PUBLISH is used when there is a software agent of some sort representing a device or service, and the ability to use that service or that device is predicated on the existence and correct operation of that agent. For the above two cases, there need not be a software agent that runs in order for the data to be meaningful, and thus xcap-pidf. Probably it needs to be expressed better, but hopefully the idea makes sense. Thanks, Jonathan R. Markus.Isomaki@nokia.com wrote: > Hi all, > > The approach presented in Data Model for Presence (http://www.ietf.org/internet-drafts/draft-rosenberg-simple-presence-data-model-00.txt) has been in principle approved in SIMPLE WG, but there are still some open issues on details. One of them concerns the scope of XCAP application usage for PIDF manipulation (http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pidf-manipulation-usage-01.txt). The Data Model draft has the following text in Chapter 10: > > One of the source of confusion around the XCAP manipulation of > PIDF [17] is that it was unclear as to why one would use it as > opposed to PUBLISH. The presence data model presented here sheds > some light on that. PUBLISH is appropriate for communicating > information about services and devices. PUBLISH is designed for > the model where there can be more than one such source (as there > is for devices and servcies), and where such state is soft-state > (as it should be for devices and services). However, presentity > state is not clearly soft-state, and the model here clearly > indicates that each presence document can have a single presentity > element. Thus, it might make sense to change the > pidf-manipulation spec to only allow setting of presentity tuples. > Now, that doesnt forbid a source from trying to PUBLISH presentity > information, but there is clearly a need for a hard-state approach > for setting presentity information. > > The concrete issue here is whether XCAP PIDF manipulation should be restricted to setting only presentity tuple, i.e. not allow the setting of service tuples or device information. > > My opinion is that we should not make this kind of restriction. > > There is at least one use case where "hard state" service tuples make a lot of sense, and that is service tuples for "persistent" services such as e-mail, SMS, MMS or voicemail. These communication means are available for the sender even if the recipient is not on-line wrt. that service, since there is a network-based "inbox" taking care of them. XCAP PIDF manipulation is a better way to describe this kind "off-line" state for such services rather than SIP PUBLISH. (BTW, I believe we should define some new status attribute to this kind of services to clearly indicate the difference between "MMS available but no device on-line" vs. "MMS available with a device on-line" etc. Or probably the standardization fora responsible for e.g. MMS can do that.) > > What might be a useful specification is to say that in a typical scenario information derived from SIP PUBLISH takes presedence over the information derived from XCAP. But that is already in the territory of specifying the composer policy, which I think is a separate effort from the data model of XCAP PIDF manipulation drafts. > > So my proposal is basically to keep the XCAP PIDF manipulation draft as it is at the moment, and not make any restricting statements about its use in the Data Model either. Are there other opinions on this topic? > > Regards, > Markus > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 29 04:37:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07299; Wed, 29 Sep 2004 04:37:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCa5q-0008U3-2h; Wed, 29 Sep 2004 04:45:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCZmT-0003gw-1t; Wed, 29 Sep 2004 04:25:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCZe8-0002LX-27 for simple@megatron.ietf.org; Wed, 29 Sep 2004 04:17:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05769 for ; Wed, 29 Sep 2004 04:17:05 -0400 (EDT) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCZm7-00083j-R2 for simple@ietf.org; Wed, 29 Sep 2004 04:25:24 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8T8H4127458 for ; Wed, 29 Sep 2004 11:17:05 +0300 (EET DST) X-Scanned: Wed, 29 Sep 2004 11:16:39 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i8T8Gdsi006554 for ; Wed, 29 Sep 2004 11:16:39 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00t4mUde; Wed, 29 Sep 2004 11:14:00 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8T8DrS02383 for ; Wed, 29 Sep 2004 11:13:53 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 29 Sep 2004 11:13:06 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe023.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 29 Sep 2004 11:13:06 +0300 Received: ESEBE054.NOE.Nokia.com 172.21.143.44 from 172.21.148.134 172.21.148.134 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost by ESEBE054.NOE.Nokia.com; 29 Sep 2004 11:13:05 +0300 Subject: Re: [Simple] Presence Data Model: Identifying services From: Aki Niemi To: "ext Markus.Isomaki@nokia.com" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1096445584.6980.81.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 29 Sep 2004 11:13:05 +0300 X-OriginalArrivalTime: 29 Sep 2004 08:13:06.0386 (UTC) FILETIME=[262A3B20:01C4A5FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Cc: SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Hi Markus, I think the service-features draft is 50% right. As you also point out, the URI scheme provides rudimentary service classification that in most cases is sufficient and provides helpful information for the watcher. But I also don't quite agree with the way service-features uses prescaps to advertize service capabilities. A super-UA may boast a range of capabilities leaving the watcher clueless about the actual combinations of those capabilities that will work. In fact, the more capabilities the UA boasts, the more useless the information -- the watcher will have to resort to "trial-and-error", which is anyway the default behavior in the absence of any prescaps. Splitting the information into separate tuples, each describing a specific "service" offered will suffer from the same or worse "combinatorial explosion" that the draft describes. I guess I also somewhat agree with Paul's argument that your proposal merely adds syntax without assigning semantics. Also, XML already has a fairly clean namespace structure, so the Java-style naming convention seems superfluous. In general, there seems at least three orthogonal things a presentity may want to communicate to the watcher: i) what communications mean to use? * Including what capabilities this medium has * In practice, the + prescaps ii) what "application" am I running? * This is basically the service-id element iii) in what state is that application? * Currently not covered * Application specific This in mind, I think we are ultimately talking about extending the element to express application-specific statuses. After all, I may have several SIP-based applications that are all in a different state. For example, I may be in "accepting-new-chess-moves" for my chess application (running on IM), but in a "please-don't-disturb" mode for push to talk. A status extension would implicitly also carry something akin to a service-id, but instead of just a simple ID, it would have real meaningful status information as well. But, I don't know if there is much to standardize here beyond explicitly mentioning that this is the best extension point for application-id type features in presence. Seems natural that we should discuss this point in the data model for presence. Cheers, Aki On Thu, 2004-09-23 at 11:10, ext Markus.Isomaki@nokia.com wrote: > Hi all, > > I have a comment on Presence Data Model draft about the identification/characterization of services. (I know this has been discussed for a while already, but I still think the current way is somewhat unadequate.) > > The current Data Model draft says: > > In this model, services are not explicitly enumerated. That is, > there is no "service" attribute with values of "ptt" or "telephony". > Rather, the service is identified in one of two ways. In many cases, > the URI scheme is a clear indicator of service. An "sms" URI clearly > indicates SMS, and a "tel" URI clearly indicates telephony. For some > URIs, there may be many services available, for example, SIP. For > those services, each service has a set of characteristics, each of > which has a well-defined meaning, such that a system can > unequivocally determine whether or not the service has that > characteristic. This is discussed in more detail in [5]. > > I agree that the contact URI scheme is the most important piece of information to distinguish what is the "service". (There are some gaps here too, since e.g. the URI schemes for SMS or MMS do not even exist, and there may be other non-IETF protocols that face the same problem.) However, I'm not convinced that listing the signaling/media characteristics of the end-point or service really gives enough information to the watcher to really determine if it can communicate with the advertised service/application. > > The refenced draft [5] has a following example: > > 5.6 Walkie-talkie > > The walkie-talkie service allows real-time voice communication > between participants. Only one participant can speak at a time; that > is, communication is half-duplex. Typically, participants press a > button to indicate that they are ready to speak, although other > mechanism (e.g. voice activation) are occasionally used. > > Support for the Walkie-Talkie service can be deduced by observing the > presence of a contact URI with a scheme of "sip:", associated with > the following minimal set of capabilities: > half INVITE,ACK,BYE,CANCEL > > Presumably this is the same as the service sometimes called Push-to-Talk (PTT, PoC). The concrete problem is that there are several _non-interworking_ variants of this service, that still all would match the characteristics listed above, as the _SIP_ part might still be standard, at least for some methods etc. But still the communication would fail even if the tuple looks OK. (Also if I saw the characteristics above, I could as well determine that they describe normal VoIP application running in (very) some old PC with half-duplex audio drivers, so I claim the service description is hard to make unambiguous in the first place.) > > I think the main point of a service tuple is to give the watcher enough information to know whether he can really communicate & interoperate with the advertised service. Given that many services taht are using SIP also have propritary or non-SIP features, I don't think the current approach is enough. > > Of course each of these proprietary services are allowed to define additional status or tuple-level extensions to PIDF. However, I would like to have some kind of "service identifier" as part of the basic framework so that this could be done in a consistent manner. I think it would help especially in making of authorization and composition rules more simple. The current "class" attribute is way too loosely defined. > > So the concrete proposal is to include in RPID a "service id" element that would have a vendor-specific namespace, similar to e.g. vendor-specific XCAP AUIDs. So for instance the SIP-based PTT app from vendor xyz.com would have, e.g. > > com.xyz.ptt > > while the PTT app compliant with OMA would have, e.g. > > com.openmobilealliance.ptt > > in _addition_ to describing sip:, half-duplex audio, and the supported methods. Now: > 1.) Watcher having one of those apps could see right away whether it is possible to communicate > 2.) Composer getting PUBLISHes from 2 sources could immediately know that they are from a similar app > 3.) The app could set its authorization rules using the unique id. > > The main downside I can see in this approach that if there are two different proprietary apps that indeed could communicate at least partially, the watcher might make a conclusion that communication is not possible baed on different service-id. However, in this case the watcher still would have the characteristics visible and could determine that some interworking could be achieved. For this kind of reasons there should be careful text about when to use service-id in the first place, and what can be determined from it. > > Does someone think that this is an absolutely bad idea? If so, how would you envision solving the issues discussed above? > > Regards, > Markus > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 29 10:59:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10815; Wed, 29 Sep 2004 10:59:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCg38-0008V7-J5; Wed, 29 Sep 2004 11:07:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCfn9-0005be-Bk; Wed, 29 Sep 2004 10:50:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCfhB-0003gp-9Z for simple@megatron.ietf.org; Wed, 29 Sep 2004 10:44:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09890 for ; Wed, 29 Sep 2004 10:44:38 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCfpD-0008AX-M4 for simple@ietf.org; Wed, 29 Sep 2004 10:53:01 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 29 Sep 2004 11:01:39 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8TEiAbx004257; Wed, 29 Sep 2004 10:44:11 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-208.cisco.com [64.100.229.208]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCI55022; Wed, 29 Sep 2004 07:44:09 -0700 (PDT) Message-Id: <4.3.2.7.2.20040929103449.00b0e058@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Sep 2004 10:44:09 -0400 To: Jonathan Rosenberg , Simple WG From: Mike Hammer Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean? In-Reply-To: <4159D7CD.3010600@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Jonathan, I'm having a sense of deja vu here. I thought previous discussions led to the conclusion that idle means exactly that, i.e. no activity since some time point, which may or may not be provided, depending on whether the idler felt that this would violate privacy. The conclusion that one could jump to based on such an indication would be implicit to the type of service, device, or person. The likelihood of a no answer is conditional and thus requires some intelligence to guess that. I thought this would be left to humans that have such cognitive skills. While lack of user input is the most likely basis, this can be fooled or not depending on what the thing reporting is. Does a user include automatons? I would say that is an implementation detail and just leave it at a "no activity since" definition. I see no reason to constrain this. My 2 cents from the peanut gallery. Mike At 05:29 PM 9/28/2004 -0400, Jonathan Rosenberg wrote: >This isn't really an issue with the data model so much as rpid, but its >used as an example in the data model. > >The question is, in the context of the data model, what does mean? >Does apply to a person? To a device? To a service? For each case, >what does it mean? Does it merely mean, "the likelihood is that attempts >to reach this service will result in a no-answer", or is it something more >specific, such as "idle indicates that no user input has been provided to >this device (service) recently". > >The first question is to determine its definition, I think. Once you know >what it means, you can decide whether it applies to devices, services or >person. I'm somewhat on the fence here. One argument is that you want a >concise and measurable definition, so that a PUA can concretely say, "this >service is idle", and have the recipient of the document know what it >means. That would argue for something based on user input. The problem >with that definition is that ultimately, the lack of user input is useful >because it is an indicator of the real quantity of interest - the >likelihood that I'll get a "no answer". So, why not define it as the data >we really want. The problem is that you will see vast differences across >devices in declaring themselves idle, and thus differing interpretations >of what to do when you see it in a document. Feature or bug? You decide. > >At this moment, I'm inclined to the concrete definition (lack of user >input), and have it be associated with the device, not the service. I know >others have different opinions. Lets sort this out. > >[this is the final open issue I am aware of] > >Thanks, >Jonathan R. >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 29 11:28:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12385; Wed, 29 Sep 2004 11:28:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCgW1-0000bn-Ek; Wed, 29 Sep 2004 11:37:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCgC5-00027n-0J; Wed, 29 Sep 2004 11:16:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCfvC-0007Wt-U3 for simple@megatron.ietf.org; Wed, 29 Sep 2004 10:59:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10838 for ; Wed, 29 Sep 2004 10:59:08 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCg3F-0008Uf-7a for simple@ietf.org; Wed, 29 Sep 2004 11:07:30 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 29 Sep 2004 08:02:15 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8TEwWlr004740; Wed, 29 Sep 2004 07:58:33 -0700 (PDT) Received: from cisco.com (che-vpn-cluster-1-56.cisco.com [10.86.240.56]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALX52608; Wed, 29 Sep 2004 10:58:34 -0400 (EDT) Message-ID: <415ACD9A.5000004@cisco.com> Date: Wed, 29 Sep 2004 10:58:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Scope of XCAP PIDF manipulation wrt. Presence Data Model References: <415A393F.3050900@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Jonathan, I agree with you and Markus on the validity of Markus's suggested usage. And I agree the kind of clarification you suggest would be helpful. But I don't think this is normative behavior, so lets make sure the language isn't too strong. (All of these attributes should be possible to manipulate *either* via XCAP or PUBLISH. Paul Jonathan Rosenberg wrote: > Markus, > > You make a good point about another use case for the pidf manipulation. > > Based on this, I think the pidf-manipulation draft needs to more > carefully outline the use cases. I think it would be good to point out > that it is ideal for: > > (1) manipulating person information, > (2) manipulating services that operate in the absence of agents that > actively run on behalf of the user (email, for example) > > In essence, then, the distinction is that PUBLISH is used when there is > a software agent of some sort representing a device or service, and the > ability to use that service or that device is predicated on the > existence and correct operation of that agent. For the above two cases, > there need not be a software agent that runs in order for the data to be > meaningful, and thus xcap-pidf. > > Probably it needs to be expressed better, but hopefully the idea makes > sense. > > Thanks, > Jonathan R. > > Markus.Isomaki@nokia.com wrote: > >> Hi all, >> >> The approach presented in Data Model for Presence >> (http://www.ietf.org/internet-drafts/draft-rosenberg-simple-presence-data-model-00.txt) >> has been in principle approved in SIMPLE WG, but there are still some >> open issues on details. One of them concerns the scope of XCAP >> application usage for PIDF manipulation >> (http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pidf-manipulation-usage-01.txt). >> The Data Model draft has the following text in Chapter 10: >> One of the source of confusion around the XCAP manipulation of >> PIDF [17] is that it was unclear as to why one would use it as >> opposed to PUBLISH. The presence data model presented here sheds >> some light on that. PUBLISH is appropriate for communicating >> information about services and devices. PUBLISH is designed for >> the model where there can be more than one such source (as there >> is for devices and servcies), and where such state is soft-state >> (as it should be for devices and services). However, presentity >> state is not clearly soft-state, and the model here clearly >> indicates that each presence document can have a single presentity >> element. Thus, it might make sense to change the >> pidf-manipulation spec to only allow setting of presentity tuples. >> Now, that doesnt forbid a source from trying to PUBLISH presentity >> information, but there is clearly a need for a hard-state approach >> for setting presentity information. >> >> The concrete issue here is whether XCAP PIDF manipulation should be >> restricted to setting only presentity tuple, i.e. not allow the >> setting of service tuples or device information. >> >> My opinion is that we should not make this kind of restriction. >> There is at least one use case where "hard state" service tuples make >> a lot of sense, and that is service tuples for "persistent" services >> such as e-mail, SMS, MMS or voicemail. These communication means are >> available for the sender even if the recipient is not on-line wrt. >> that service, since there is a network-based "inbox" taking care of >> them. XCAP PIDF manipulation is a better way to describe this kind >> "off-line" state for such services rather than SIP PUBLISH. (BTW, I >> believe we should define some new status attribute to this kind of >> services to clearly indicate the difference between "MMS available but >> no device on-line" vs. "MMS available with a device on-line" etc. Or >> probably the standardization fora responsible for e.g. MMS can do that.) >> >> What might be a useful specification is to say that in a typical >> scenario information derived from SIP PUBLISH takes presedence over >> the information derived from XCAP. But that is already in the >> territory of specifying the composer policy, which I think is a >> separate effort from the data model of XCAP PIDF manipulation drafts. >> >> So my proposal is basically to keep the XCAP PIDF manipulation draft >> as it is at the moment, and not make any restricting statements about >> its use in the Data Model either. Are there other opinions on this topic? >> >> Regards, >> Markus >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 29 11:34:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12758; Wed, 29 Sep 2004 11:34:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCgaz-0000k8-Co; Wed, 29 Sep 2004 11:42:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCgMq-0004mu-KI; Wed, 29 Sep 2004 11:27:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCgAl-0001UY-5X for simple@megatron.ietf.org; Wed, 29 Sep 2004 11:15:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11545 for ; Wed, 29 Sep 2004 11:15:12 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCgIm-0000It-OU for simple@ietf.org; Wed, 29 Sep 2004 11:23:35 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 29 Sep 2004 11:32:05 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8TFEabx010575; Wed, 29 Sep 2004 11:14:37 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-208.cisco.com [64.100.229.208]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCI57909; Wed, 29 Sep 2004 08:14:35 -0700 (PDT) Message-Id: <4.3.2.7.2.20040929110138.00b15708@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Sep 2004 11:14:35 -0400 To: Henning Schulzrinne , Jonathan Rosenberg From: Mike Hammer Subject: Re: [Simple] Pres Data Model Open Issue #1: in-person communications In-Reply-To: <4159FB36.9090502@cs.columbia.edu> References: <4159D228.5040905@dynamicsoft.com> <4159D228.5040905@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe The location information is not the presentity, but an attribute of the in-person capability. What about providing a postal availability to tell your friends that you are in town, in a hotel, in the lobby for direct communication, rather that have two people on opposite sides of the same lobby (perhaps obscured by a plant) trying to talk over cell phones? I think the possibility of using presence to determine proximity is a useful indication. So long as this can be deduced from the information provided in the presence document, then this issue is covered. Mike At 08:00 PM 9/28/2004 -0400, Henning Schulzrinne wrote: >I agree, although the two examples you give are rather different in their >usefulness. > >In practice, status information for the postal elements is not >particularly useful as it doesn't tend to change a lot. Your postal >availability is not exactly something subject to OPEN/CLOSED. Plus, the >CIPID vcard element already allows to express this. > >The in-person indication is definitely more useful for coordination. I'd >argue you'd actually want a "protocol" indication, not a URN indication, >since you've already identified the person. > >As you said, this can easily be solved by a convention, maybe suitably >defined in an April 1 RFC, along with the carrier pigeon URL. > >Jonathan Rosenberg wrote: > >>Currently, there is no easy way to incorporate the notion of "in person" >>or "written/postal" communications as services represented in the data >>model. The reason is that there is no URI scheme for them, and no >>attributes that can be used to define them. The issue is, what to do >>about this? >>My proposal is to punt the issue in this document. State that it is >>expected that future specifications will address how to represent these. >>To actually solve the problem, I think the right approach is to define a >>URN scheme along the lines of "urn:inperson" to represent an in-person >>communications scheme. For postal communications, I think you want a URN >>that includes the postal address, something like >>urn:postal:sname=Lanidex%20Plaza-snumber=600-state=NJ-city=Parsippany-zip=07054 >>or something like that. Thats probably a fairly hard problem to solve, >>and I think even less important for us to tackle. >>However, we can defer working on either of those in earnest for a bit, >>until our basic work is done. >>Comments? >>Thanks, >>Jonathan R. > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 29 11:49:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13654; Wed, 29 Sep 2004 11:49:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCgpy-00011H-4O; Wed, 29 Sep 2004 11:57:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCgRq-0005nk-Rj; Wed, 29 Sep 2004 11:32:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCgH8-0002o0-7j for simple@megatron.ietf.org; Wed, 29 Sep 2004 11:21:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11923 for ; Wed, 29 Sep 2004 11:21:47 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCgPB-0000Sr-3W for simple@ietf.org; Wed, 29 Sep 2004 11:30:10 -0400 Received: from razor.cs.columbia.edu (IDENT:UREHhUVVPOA4KAK/KN3Mfhv6oRqHOKPt@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8TFJex6016145 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 29 Sep 2004 11:19:41 -0400 (EDT) Received: from [127.0.0.1] (IDENT:y4VpFjOp+d+t6Jsvg67hzOlA5Wy+Fr6x@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8TFJdYZ032098; Wed, 29 Sep 2004 11:19:40 -0400 Message-ID: <415AD28C.3050401@cs.columbia.edu> Date: Wed, 29 Sep 2004 11:19:40 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Hammer Subject: Re: [Simple] Pres Data Model Open Issue #1: in-person communications References: <4159D228.5040905@dynamicsoft.com> <4159D228.5040905@dynamicsoft.com> <4.3.2.7.2.20040929110138.00b15708@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20040929110138.00b15708@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.9.28.8 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit I'm not sure I understand your comment completely, but general physical location for presentities, in both civic (street/city) and geospatial format, are available in the PIDF-LO document, recently finished. Note that postal addresses are often not a good approximation to physical location. (You probably don't want to meet at my PO box, but there are other cases that are less obvious.) Mike Hammer wrote: > The location information is not the presentity, but an attribute of the > in-person capability. > > What about providing a postal availability to tell your friends that you > are in town, in a hotel, in the lobby for direct communication, rather > that have two people on opposite sides of the same lobby (perhaps > obscured by a plant) trying to talk over cell phones? > > I think the possibility of using presence to determine proximity is a > useful indication. So long as this can be deduced from the information > provided in the presence document, then this issue is covered. > > Mike > > > At 08:00 PM 9/28/2004 -0400, Henning Schulzrinne wrote: > >> I agree, although the two examples you give are rather different in >> their usefulness. >> >> In practice, status information for the postal elements is not >> particularly useful as it doesn't tend to change a lot. Your postal >> availability is not exactly something subject to OPEN/CLOSED. Plus, >> the CIPID vcard element already allows to express this. >> >> The in-person indication is definitely more useful for coordination. >> I'd argue you'd actually want a "protocol" indication, not a URN >> indication, since you've already identified the person. >> >> As you said, this can easily be solved by a convention, maybe suitably >> defined in an April 1 RFC, along with the carrier pigeon URL. >> >> Jonathan Rosenberg wrote: >> >>> Currently, there is no easy way to incorporate the notion of "in >>> person" or "written/postal" communications as services represented in >>> the data model. The reason is that there is no URI scheme for them, >>> and no attributes that can be used to define them. The issue is, what >>> to do about this? >>> My proposal is to punt the issue in this document. State that it is >>> expected that future specifications will address how to represent these. >>> To actually solve the problem, I think the right approach is to >>> define a URN scheme along the lines of "urn:inperson" to represent an >>> in-person communications scheme. For postal communications, I think >>> you want a URN that includes the postal address, something like >>> urn:postal:sname=Lanidex%20Plaza-snumber=600-state=NJ-city=Parsippany-zip=07054 >>> or something like that. Thats probably a fairly hard problem to >>> solve, and I think even less important for us to tackle. >>> However, we can defer working on either of those in earnest for a >>> bit, until our basic work is done. >>> Comments? >>> Thanks, >>> Jonathan R. >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 29 12:06:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15362; Wed, 29 Sep 2004 12:06:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCh61-0001Ri-Te; Wed, 29 Sep 2004 12:14:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCgph-0001um-9H; Wed, 29 Sep 2004 11:57:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCghH-000870-84 for simple@megatron.ietf.org; Wed, 29 Sep 2004 11:48:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13558 for ; Wed, 29 Sep 2004 11:48:48 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCgpK-0000xm-05 for simple@ietf.org; Wed, 29 Sep 2004 11:57:11 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 29 Sep 2004 09:01:51 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8TFmF3c025847; Wed, 29 Sep 2004 08:48:16 -0700 (PDT) Received: from cisco.com (che-vpn-cluster-1-56.cisco.com [10.86.240.56]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALX58014; Wed, 29 Sep 2004 11:48:14 -0400 (EDT) Message-ID: <415AD93E.7080500@cisco.com> Date: Wed, 29 Sep 2004 11:48:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] Presence Data Model: Identifying services References: <1096445584.6980.81.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 7bit Cc: SIMPLE WG , "ext Markus.Isomaki@nokia.com" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: 7bit Aki, I think you make some good observations here. More inline. Paul Aki Niemi wrote: > Hi Markus, > > I think the service-features draft is 50% right. As you also point out, > the URI scheme provides rudimentary service classification that in most > cases is sufficient and provides helpful information for the watcher. > > But I also don't quite agree with the way service-features uses prescaps > to advertize service capabilities. A super-UA may boast a range of > capabilities leaving the watcher clueless about the actual combinations > of those capabilities that will work. Well, ideally the capabilities are orthogonal to one another, so that all combinations are possible and meaningful. Certainly callee capabilities notation that prescaps is based on assumes that the capabilities are orthogonal. If this is not the case then some other representation is called for. (E.g. multiple tuples) > In fact, the more capabilities the > UA boasts, the more useless the information -- the watcher will have to > resort to "trial-and-error", which is anyway the default behavior in the > absence of any prescaps. > > Splitting the information into separate tuples, each describing a > specific "service" offered will suffer from the same or worse > "combinatorial explosion" that the draft describes. To some extent this is in the hands of the device implementors. If there are lots of complex rules about what can be used with what, then the description of the device with inherently either be complex or imprecise. The obvious answer is: if it hurts, don't do it. > I guess I also somewhat agree with Paul's argument that your proposal > merely adds syntax without assigning semantics. Also, XML already has a > fairly clean namespace structure, so the Java-style naming convention > seems superfluous. > > In general, there seems at least three orthogonal things a presentity > may want to communicate to the watcher: > > i) what communications mean to use? > * Including what capabilities this medium has > * In practice, the + prescaps > ii) what "application" am I running? > * This is basically the service-id element I finally start to warm to the concept when it is described this way. I think we already have *some* notion of this concept of application within callerprefs/calleecaps: certainly actor=msg-taker (and maybe actor=attendant) are describing a form of application. Perhaps this should be generalized further. If so, I think it has as much value for callerprefs as it does for presence, so I would argue for adding it to callee caps first and then bringing it into presence via prescaps. I think it is going to be quite difficult to come up with a clear and concise discrimination between what is an application and what is communications means. Luckily, if done via prescaps there is no real need to make the distinction. > iii) in what state is that application? > * Currently not covered > * Application specific > > This in mind, I think we are ultimately talking about extending the > element to express application-specific statuses. After all, I > may have several SIP-based applications that are all in a different > state. For example, I may be in "accepting-new-chess-moves" for my chess > application (running on IM), but in a "please-don't-disturb" mode for > push to talk. That seems like kind of a mixed bag for a single tuple. It sounds like a valid application for multiple tuples. (Would I really have have the IM at this address dedicated to chess, while the PTT isn't? I don't think so.) I have a sense that the "applications" that share an address are really just part of the means of communication. A "real" application would probably utilize all the communication modalities that are available at that address - if it didn't, they wouldn't be available. > A status extension would implicitly also carry something akin to a > service-id, but instead of just a simple ID, it would have real > meaningful status information as well. > > But, I don't know if there is much to standardize here beyond explicitly > mentioning that this is the best extension point for application-id type > features in presence. Seems natural that we should discuss this point in > the data model for presence. > > Cheers, > Aki > > > On Thu, 2004-09-23 at 11:10, ext Markus.Isomaki@nokia.com wrote: > >>Hi all, >> >>I have a comment on Presence Data Model draft about the identification/characterization of services. (I know this has been discussed for a while already, but I still think the current way is somewhat unadequate.) >> >>The current Data Model draft says: >> >> In this model, services are not explicitly enumerated. That is, >> there is no "service" attribute with values of "ptt" or "telephony". >> Rather, the service is identified in one of two ways. In many cases, >> the URI scheme is a clear indicator of service. An "sms" URI clearly >> indicates SMS, and a "tel" URI clearly indicates telephony. For some >> URIs, there may be many services available, for example, SIP. For >> those services, each service has a set of characteristics, each of >> which has a well-defined meaning, such that a system can >> unequivocally determine whether or not the service has that >> characteristic. This is discussed in more detail in [5]. >> >>I agree that the contact URI scheme is the most important piece of information to distinguish what is the "service". (There are some gaps here too, since e.g. the URI schemes for SMS or MMS do not even exist, and there may be other non-IETF protocols that face the same problem.) However, I'm not convinced that listing the signaling/media characteristics of the end-point or service really gives enough information to the watcher to really determine if it can communicate with the advertised service/application. >> >>The refenced draft [5] has a following example: >> >>5.6 Walkie-talkie >> >> The walkie-talkie service allows real-time voice communication >> between participants. Only one participant can speak at a time; that >> is, communication is half-duplex. Typically, participants press a >> button to indicate that they are ready to speak, although other >> mechanism (e.g. voice activation) are occasionally used. >> >> Support for the Walkie-Talkie service can be deduced by observing the >> presence of a contact URI with a scheme of "sip:", associated with >> the following minimal set of capabilities: >> half INVITE,ACK,BYE,CANCEL >> >>Presumably this is the same as the service sometimes called Push-to-Talk (PTT, PoC). The concrete problem is that there are several _non-interworking_ variants of this service, that still all would match the characteristics listed above, as the _SIP_ part might still be standard, at least for some methods etc. But still the communication would fail even if the tuple looks OK. (Also if I saw the characteristics above, I could as well determine that they describe normal VoIP application running in (very) some old PC with half-duplex audio drivers, so I claim the service description is hard to make unambiguous in the first place.) >> >>I think the main point of a service tuple is to give the watcher enough information to know whether he can really communicate & interoperate with the advertised service. Given that many services taht are using SIP also have propritary or non-SIP features, I don't think the current approach is enough. >> >>Of course each of these proprietary services are allowed to define additional status or tuple-level extensions to PIDF. However, I would like to have some kind of "service identifier" as part of the basic framework so that this could be done in a consistent manner. I think it would help especially in making of authorization and composition rules more simple. The current "class" attribute is way too loosely defined. >> >>So the concrete proposal is to include in RPID a "service id" element that would have a vendor-specific namespace, similar to e.g. vendor-specific XCAP AUIDs. So for instance the SIP-based PTT app from vendor xyz.com would have, e.g. >> >>com.xyz.ptt >> >>while the PTT app compliant with OMA would have, e.g. >> >>com.openmobilealliance.ptt >> >>in _addition_ to describing sip:, half-duplex audio, and the supported methods. Now: >>1.) Watcher having one of those apps could see right away whether it is possible to communicate >>2.) Composer getting PUBLISHes from 2 sources could immediately know that they are from a similar app >>3.) The app could set its authorization rules using the unique id. >> >>The main downside I can see in this approach that if there are two different proprietary apps that indeed could communicate at least partially, the watcher might make a conclusion that communication is not possible baed on different service-id. However, in this case the watcher still would have the characteristics visible and could determine that some interworking could be achieved. For this kind of reasons there should be careful text about when to use service-id in the first place, and what can be determined from it. >> >>Does someone think that this is an absolutely bad idea? If so, how would you envision solving the issues discussed above? >> >>Regards, >> Markus >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 29 12:21:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16771; Wed, 29 Sep 2004 12:21:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CChL0-0001mc-W9; Wed, 29 Sep 2004 12:29:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCgxH-00043O-TE; Wed, 29 Sep 2004 12:05:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCgmm-0001WY-6g for simple@megatron.ietf.org; Wed, 29 Sep 2004 11:54:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14384 for ; Wed, 29 Sep 2004 11:54:29 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCguq-0001C5-CX for simple@ietf.org; Wed, 29 Sep 2004 12:02:52 -0400 Received: from razor.cs.columbia.edu (IDENT:km5xLH3jjb7vNJ1aMGD+BLsGEEbhIL8M@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8TFsNx6028333 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 29 Sep 2004 11:54:23 -0400 (EDT) Received: from [127.0.0.1] (IDENT:QmY7xeT7tyU2yATmH/ohL0lWkhLXwF7i@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8TFsMYZ032653; Wed, 29 Sep 2004 11:54:23 -0400 Message-ID: <415ADAAF.3040700@cs.columbia.edu> Date: Wed, 29 Sep 2004 11:54:23 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean? References: <4159D7CD.3010600@dynamicsoft.com> In-Reply-To: <4159D7CD.3010600@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.9.28.8 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > The question is, in the context of the data model, what does > mean? Does apply to a person? To a device? To a service? For each > case, what does it mean? Does it merely mean, "the likelihood is that > attempts to reach this service will result in a no-answer", or is it > something more specific, such as "idle indicates that no user input has > been provided to this device (service) recently". The likelihood of reachability is defined by other things besides the lack of user input or similar metrics. Calling "likelihood of reachability" seems a bit odd, although lack of usage is clearly a factor in gauging such probability. The RPID draft tries to state this currently. > > The first question is to determine its definition, I think. Once you > know what it means, you can decide whether it applies to devices, > services or person. I'm somewhat on the fence here. One argument is that > you want a concise and measurable definition, so that a PUA can > concretely say, "this service is idle", and have the recipient of the > document know what it means. That would argue for something based on > user input. The problem with that definition is that ultimately, the > lack of user input is useful because it is an indicator of the real > quantity of interest - the likelihood that I'll get a "no answer". So, But there are lots of reasons for 'no answer'. I might be in a movie theater or driving and decide not to answer your call. I might be out of coverage area, etc. In many cases, is not a terribly good indication of likelihood of answer. I make very few calls on my cell phone, i.e., it would be idle by any reasonable definition, but it is certainly reachable. For a person who walks around with an earbud and is exceeding their 5000-minutes-a-month allotment, idleness may indeed be an indication of not being able to be reached. > why not define it as the data we really want. The problem is that you > will see vast differences across devices in declaring themselves idle, > and thus differing interpretations of what to do when you see it in a > document. Feature or bug? You decide. I think the general approach in RPID has been to provide reasonably well-defined input data which is then interpreted, combining multiple pieces of information and maybe historical data, to guide communications or qualitative reachability. (For example, a smart watcher may correlate various factors into a reachability score, based on previous "experiments".) > > At this moment, I'm inclined to the concrete definition (lack of user > input), and have it be associated with the device, not the service. I > know others have different opinions. Lets sort this out. I disagree with the 'device, not service'. I can easily detect non-usage for a service and it seems to be as valuable for that service as for some piece of plastic. > > [this is the final open issue I am aware of] > > Thanks, > Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 29 13:54:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23130; Wed, 29 Sep 2004 13:54:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCimb-0003i4-Ka; Wed, 29 Sep 2004 14:02:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCiSm-0003do-Ur; Wed, 29 Sep 2004 13:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCiAm-000412-54 for simple@megatron.ietf.org; Wed, 29 Sep 2004 13:23:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20734 for ; Wed, 29 Sep 2004 13:23:20 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCiIr-0002zs-1W for simple@ietf.org; Wed, 29 Sep 2004 13:31:45 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 29 Sep 2004 13:22:54 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8THMo7A013652; Wed, 29 Sep 2004 13:22:50 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-64-100-224-248.cisco.com [64.100.224.248]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCI69880; Wed, 29 Sep 2004 10:22:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20040929121646.00b30118@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Sep 2004 13:22:49 -0400 To: Henning Schulzrinne From: Mike Hammer Subject: Re: [Simple] Pres Data Model Open Issue #1: in-person communications In-Reply-To: <415AD28C.3050401@cs.columbia.edu> References: <4.3.2.7.2.20040929110138.00b15708@cia.cisco.com> <4159D228.5040905@dynamicsoft.com> <4159D228.5040905@dynamicsoft.com> <4.3.2.7.2.20040929110138.00b15708@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Jonathan Rosenberg , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 On the other hand, not all folks carry GPS devices, so the ability somewhere to convert a Lat/Long to a street address is useful. But, to clarify my early point, if the person location information is available via presence, then the need to define an in-person communications means is probably moot. Mike At 11:19 AM 9/29/2004 -0400, Henning Schulzrinne wrote: >I'm not sure I understand your comment completely, but general physical >location for presentities, in both civic (street/city) and geospatial >format, are available in the PIDF-LO document, recently finished. Note >that postal addresses are often not a good approximation to physical >location. (You probably don't want to meet at my PO box, but there are >other cases that are less obvious.) > >Mike Hammer wrote: > >>The location information is not the presentity, but an attribute of the >>in-person capability. >>What about providing a postal availability to tell your friends that you >>are in town, in a hotel, in the lobby for direct communication, rather >>that have two people on opposite sides of the same lobby (perhaps >>obscured by a plant) trying to talk over cell phones? >>I think the possibility of using presence to determine proximity is a >>useful indication. So long as this can be deduced from the information >>provided in the presence document, then this issue is covered. >>Mike >> >>At 08:00 PM 9/28/2004 -0400, Henning Schulzrinne wrote: >> >>>I agree, although the two examples you give are rather different in >>>their usefulness. >>> >>>In practice, status information for the postal elements is not >>>particularly useful as it doesn't tend to change a lot. Your postal >>>availability is not exactly something subject to OPEN/CLOSED. Plus, the >>>CIPID vcard element already allows to express this. >>> >>>The in-person indication is definitely more useful for coordination. I'd >>>argue you'd actually want a "protocol" indication, not a URN indication, >>>since you've already identified the person. >>> >>>As you said, this can easily be solved by a convention, maybe suitably >>>defined in an April 1 RFC, along with the carrier pigeon URL. >>> >>>Jonathan Rosenberg wrote: >>> >>>>Currently, there is no easy way to incorporate the notion of "in >>>>person" or "written/postal" communications as services represented in >>>>the data model. The reason is that there is no URI scheme for them, and >>>>no attributes that can be used to define them. The issue is, what to do >>>>about this? >>>>My proposal is to punt the issue in this document. State that it is >>>>expected that future specifications will address how to represent these. >>>>To actually solve the problem, I think the right approach is to define >>>>a URN scheme along the lines of "urn:inperson" to represent an >>>>in-person communications scheme. For postal communications, I think you >>>>want a URN that includes the postal address, something like >>>>urn:postal:sname=Lanidex%20Plaza-snumber=600-state=NJ-city=Parsippany-zip=07054 >>>>or something like that. Thats probably a fairly hard problem to solve, >>>>and I think even less important for us to tackle. >>>>However, we can defer working on either of those in earnest for a bit, >>>>until our basic work is done. >>>>Comments? >>>>Thanks, >>>>Jonathan R. >>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 29 15:11:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00030; Wed, 29 Sep 2004 15:11:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCjzK-0005TC-CO; Wed, 29 Sep 2004 15:19:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCjXD-0006eL-2w; Wed, 29 Sep 2004 14:50:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCjGP-00038O-MW for simple@megatron.ietf.org; Wed, 29 Sep 2004 14:33:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26600 for ; Wed, 29 Sep 2004 14:33:15 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCjOU-0004VF-9M for simple@ietf.org; Wed, 29 Sep 2004 14:41:38 -0400 Received: from razor.cs.columbia.edu (IDENT:XvPpYuDIruJr97B1dDnFjrdz2Z9356bF@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8TIX6x6012859 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 29 Sep 2004 14:33:07 -0400 (EDT) Received: from [127.0.0.1] (IDENT:YLjZWgiA7yurnrYXQzOfIJrsBLqpoSRm@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8TIX5YZ001400; Wed, 29 Sep 2004 14:33:06 -0400 Message-ID: <415AFFE2.1020705@cs.columbia.edu> Date: Wed, 29 Sep 2004 14:33:06 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Pres Data Model Issue #4, indicating the source of data References: <4159D600.8010201@dynamicsoft.com> In-Reply-To: <4159D600.8010201@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.9.29.0 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Similar work will have to be done for geolocation, as this is quite important for 911 services to debug when things go wrong. I suspect some of the considerations are similar. (You want to know, for example, whether the information is native or has been translated and combined in some way.) Also, in general, different pieces of information are likely to have different types of sources. For location information, you want to know whether this is from GPS or LORAN. Other items will have different labeling requirements. In short: not only out of scope for a general document for getting-done reasons, but likely to be highly content-dependent and best handled for each type of information. Jonathan Rosenberg wrote: > The data model draft spends a fair bit of time talking about conflicting > data, and how a presence server can resolve the conflicts. One of the > things it talks about is making use of presence meta-data, and in > particular, the source of a piece of presence data, as a tool in > deciding how to resolve conflicts. > > The question is, do we want to do any work in defining ways of > identifying the source of the presence information? > > I am strongly inclined to say "no", and simply leave this as a potential > future issue to address. I would modify the data model draft to talk > about meta-data, but not say anything about future standardization or > any specific specs where such meta-data are defined. > > Comments? > > Thanks, > Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 29 15:12:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00207; Wed, 29 Sep 2004 15:12:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCk0F-0005V2-Fx; Wed, 29 Sep 2004 15:20:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCjXJ-0006qu-Vw; Wed, 29 Sep 2004 14:50:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCjIc-0003Kt-K3 for simple@megatron.ietf.org; Wed, 29 Sep 2004 14:35:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26794 for ; Wed, 29 Sep 2004 14:35:32 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCjQi-0004XT-5M for simple@ietf.org; Wed, 29 Sep 2004 14:43:56 -0400 Received: from razor.cs.columbia.edu (IDENT:VZq/C9N6gU2G11OgRQYDxTsc/EOCYHRC@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8TIZTx6013290 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 29 Sep 2004 14:35:30 -0400 (EDT) Received: from [127.0.0.1] (IDENT:ikPFc9jAOBT2A3BKpt/InE1fRh9dfonx@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i8TIZTYZ001417; Wed, 29 Sep 2004 14:35:29 -0400 Message-ID: <415B0072.60109@cs.columbia.edu> Date: Wed, 29 Sep 2004 14:35:30 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Pres Data Model Open Issue #3, UUID URN or something else References: <4159D54F.5060700@dynamicsoft.com> In-Reply-To: <4159D54F.5060700@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.9.29.0 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit As discussed previously, a device may not even have a MAC or may have several (if it is a composite or a multi-homed device). Thus, this seems inherently difficult. We went through this whole discussion before, I believe. Jonathan Rosenberg wrote: > One of the things the design team spent a lot of time discussing was > what a device ID looked like. Our conclusion, as documented in the I-D, > is that its a URN. We can't lock down the specific type of URN, but for > things where MAC address is a useful unique device identifier, the UUID > URN (as it makes use of a MAC address) is a good choice. > > However, upon a more detailed read of the UUID URN specification, I am > not sure we can use it. The reason is that the UUID URN spec > (http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-03.txt) > describes several ways of computing the URN. There are actually four > versions. The time-based version uses the host MAC, along with the > current time, to generate the UUID. The name-based version doesnt use > time, but relies on a unique namespace, such as DNS or URIs, as a seed. > MAC address is not a choice. > > So, the problem is, the UUID form that utilizes the MAC address also > includes a time-based component. This serves to provide uniqueness, but > makes it useless as a meaningful identifier that other presence sources > - like an ethernet switch or 802.11 AP, would be able to provide > information about. > > So, the options as I see them are: > > 1. use UUID URN anyway, lose the correlation properties we wanted > 2. dont specify the URN form at all > 3. don't specify the URN form in this document, but work on this problem > in downstream specifications > > I would propose approach (3). In particular, I think the data model > should revert to being agnostic on the URN scheme, reference the UUID > URN as one possibility, document its problems. We should develop a > separate specification that defines guidelines for choosing the URN for > various devices in order to get the correlation properties we want. I > also think we should take a stab at defining a few URN schemes that > would be useful - MAC and ESN in particular. > > Comments? > > Thanks, > Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Sep 29 17:21:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16582; Wed, 29 Sep 2004 17:21:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCm17-00029b-2A; Wed, 29 Sep 2004 17:29:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCkTN-0004aG-2D; Wed, 29 Sep 2004 15:50:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCk9g-0004HF-Fj; Wed, 29 Sep 2004 15:30:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02242; Wed, 29 Sep 2004 15:30:22 -0400 (EDT) Message-Id: <200409291930.PAA02242@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 29 Sep 2004 15:30:22 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-data-model-00.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : A Data Model for Presence Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-data-model-00.txt Pages : 39 Date : 2004-9-29 This document defines the underlying data model and data processing operations used by Session Initiation Protocol (SIP) for Instant Messaging Leveraging Presence Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion. The data processing operations described here include composition, privacy filtering, and watcher filtering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data-model-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-presence-data-model-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presence-data-model-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-29153557.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-data-model-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-data-model-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-29153557.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Wed Sep 29 21:14:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10959; Wed, 29 Sep 2004 21:14:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCpf6-0000MI-DC; Wed, 29 Sep 2004 21:23:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCpS4-0003xn-GI; Wed, 29 Sep 2004 21:09:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCpR3-0002rg-Fm for simple@megatron.ietf.org; Wed, 29 Sep 2004 21:08:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10516 for ; Wed, 29 Sep 2004 21:08:39 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCpZB-0000Ev-Ji for simple@ietf.org; Wed, 29 Sep 2004 21:17:06 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 29 Sep 2004 21:25:40 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8U186bx022972; Wed, 29 Sep 2004 21:08:07 -0400 (EDT) Received: from cisco.com (rtp-vpn3-527.cisco.com [10.82.218.18]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALY04721; Wed, 29 Sep 2004 21:08:06 -0400 (EDT) Message-ID: <415B5C75.9050305@cisco.com> Date: Wed, 29 Sep 2004 21:08:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean? References: <4159D7CD.3010600@dynamicsoft.com> <415ADAAF.3040700@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit I think idle makes sense for devices, services, and maybe people as well. If we say idle can only be used for devices we will have problems when there are services that are capable of reporting their own idleness but are unable to determine device idleness. Paul Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> The question is, in the context of the data model, what does >> mean? Does apply to a person? To a device? To a service? For >> each case, what does it mean? Does it merely mean, "the likelihood is >> that attempts to reach this service will result in a no-answer", or is >> it something more specific, such as "idle indicates that no user input >> has been provided to this device (service) recently". > > > The likelihood of reachability is defined by other things besides the > lack of user input or similar metrics. Calling "likelihood of > reachability" seems a bit odd, although lack of usage is clearly > a factor in gauging such probability. > > The RPID draft tries to state this currently. > > >> >> The first question is to determine its definition, I think. Once you >> know what it means, you can decide whether it applies to devices, >> services or person. I'm somewhat on the fence here. One argument is >> that you want a concise and measurable definition, so that a PUA can >> concretely say, "this service is idle", and have the recipient of the >> document know what it means. That would argue for something based on >> user input. The problem with that definition is that ultimately, the >> lack of user input is useful because it is an indicator of the real >> quantity of interest - the likelihood that I'll get a "no answer". So, > > > But there are lots of reasons for 'no answer'. I might be in a movie > theater or driving and decide not to answer your call. I might be out of > coverage area, etc. > > In many cases, is not a terribly good indication of likelihood of > answer. I make very few calls on my cell phone, i.e., it would be idle > by any reasonable definition, but it is certainly reachable. > > For a person who walks around with an earbud and is exceeding their > 5000-minutes-a-month allotment, idleness may indeed be an indication of > not being able to be reached. > > >> why not define it as the data we really want. The problem is that you >> will see vast differences across devices in declaring themselves idle, >> and thus differing interpretations of what to do when you see it in a >> document. Feature or bug? You decide. > > > I think the general approach in RPID has been to provide reasonably > well-defined input data which is then interpreted, combining multiple > pieces of information and maybe historical data, to guide communications > or qualitative reachability. (For example, a smart watcher may correlate > various factors into a reachability score, based on previous > "experiments".) > >> >> At this moment, I'm inclined to the concrete definition (lack of user >> input), and have it be associated with the device, not the service. I >> know others have different opinions. Lets sort this out. > > > I disagree with the 'device, not service'. I can easily detect non-usage > for a service and it seems to be as valuable for that service as for > some piece of plastic. > > >> >> [this is the final open issue I am aware of] >> >> Thanks, >> Jonathan R. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple