From simple-bounces@ietf.org Wed Mar 01 17:34:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEZtR-0005EN-34; Wed, 01 Mar 2006 17:34:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEZtO-0005CK-V2 for simple@ietf.org; Wed, 01 Mar 2006 17:33:58 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEZtO-0001yC-Hz for simple@ietf.org; Wed, 01 Mar 2006 17:33:58 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 1 Mar 2006 14:33:57 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.61.141]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 14:33:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 1 Mar 2006 14:33:51 -0800 Message-ID: <1BEC4DA05ABCD34FACFCFC82086AC247092E1E81@RED-MSG-43.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: contact card elements in PIDF Thread-Index: AcY9gDca3qcWquSCTvOCdqrHCeOS+w== From: "Tim Rang" To: "Simple WG" X-OriginalArrivalTime: 01 Mar 2006 22:33:57.0540 (UTC) FILETIME=[3AA15E40:01C63D80] X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Subject: [Simple] contact card elements in 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="===============1870315966==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1870315966== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63D80.37650C28" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63D80.37650C28 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm curious how other implementers are transmitting contact card attributes in PIDF documents. The CIPID draft provides for a couple of basic attributes to be reflected directly in the document, but most of them are required to passed indirectly via a element in LDIF or vCard format. This may be useful in some situations, but I think is lacking in several respects- - How to guarantee that a watcher always has access to the card. In enterprises, an internal http location may not be accessible to federated users and external storage of vcards may be unavailable. - How to set flexible permissions on contact card data. I may want to show some watchers a vCard with just my company, company address, and job title, while I want to show office number and home address to others. If I home my vcard on a web server, I can show people different URLs but I cannot guarantee that richer vCard is unavailable to more restricted watchers. =20 Has there been a proposal anywhere to place this kind of data directly in PIDF rather than at a URL? =20 =20 Thanks, Tim Rang ------_=_NextPart_001_01C63D80.37650C28 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m curious how other implementers are = transmitting contact card attributes in PIDF documents.  The CIPID draft = provides for a couple of basic attributes to be reflected directly in the document, but = most of them are required to passed indirectly via a <card> element in = LDIF or vCard format.  This may be useful in some situations, but I think = is lacking in several respects-

-          How to guarantee that a = watcher always has access to the card.  In enterprises, an internal http = location may not be accessible to federated users and external storage of vcards = may be unavailable.

-          How to set flexible = permissions on contact card data.  I may want to show some watchers a vCard with = just my company, company address, and job title, while I want to show office = number and home address to others.  If I home my vcard on a web server, I can = show people different URLs but I cannot guarantee that richer vCard is = unavailable to more restricted watchers.

 

Has there been a proposal anywhere to place this kind = of data directly in PIDF rather than at a URL?  =

 

Thanks,

Tim = Rang

------_=_NextPart_001_01C63D80.37650C28-- --===============1870315966== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1870315966==-- From simple-bounces@ietf.org Wed Mar 01 18:20:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEac2-0000dG-48; Wed, 01 Mar 2006 18:20:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEac0-0000ci-UZ for simple@ietf.org; Wed, 01 Mar 2006 18:20:04 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEaby-0003eh-JR for simple@ietf.org; Wed, 01 Mar 2006 18:20:04 -0500 X-IronPort-AV: i="4.02,158,1139202000"; d="scan'208"; a="29292416:sNHT55640712" X-MimeOLE: Produced By Microsoft Exchange V6.5 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] IMDN? Date: Wed, 1 Mar 2006 18:20:02 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664702571B32@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] IMDN? Thread-Index: AcY1Ku9bQiSkaq/BQrarHN5iuel5lQHUEItQAEKxFiA= From: "Burger, Eric" To: "Nadia Bishai \(QC/EMC\)" , "Simple WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: OMA-MWG-IM@MAIL.OPENMOBILEALLIANCE.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: , Errors-To: simple-bounces@ietf.org 1. The error would be in the relay, not in receipt at the gateway. Thus = there is no transport (CPIM) error. 2. Sending system is the UAC. If the user sends a message to a list = exploder, and the sender expects his message to get end-user responses, = he will receive end-user responses from ALL end-users, because every one = will get a Disposition-Notification header. This is just to remind = implementers of that. 3. Oops - you're right. At least someone is reading the document! = Thanks. 4. We talked about this at length; for most use cases we could think of = the user that deletes the message automatically or without "opening" the = message probably will suppress sending the report anyway. I can go = either way, but it really is not useful. 5. UAC. UAS has no state. -----Original Message----- From: Nadia Bishai (QC/EMC) [mailto:nadia.bishai@ericsson.com]=20 Sent: Tuesday, February 28, 2006 10:35 AM To: Burger, Eric; Simple WG Cc: Ignacio M=E1s Ivars (KI/EAB); OMA-MWG-IM@MAIL.OPENMOBILEALLIANCE.ORG Subject: RE: [Simple] IMDN? Hi Eric, Some questions on the draft: =20 1. What is the benefit of the UAC requesting a report from an intermediate node? The UAC will not find out if the intended recipient got the message, but if there was an error processing the message by an intermediate node, then this information would be received by the recipient anyway.=20 =20 2. In the following paragraph what is meant by the sending system?? Is it the CPIM confernce server? If so, how does it determine for which message an IMDN should be requested? =20 " For CPIM conferences, a message with a Disposition-Notification header will result in all recipients performing = IMDN processing. If this is not desirable, the sending system MUST send = multiple messages with the appropriate requests (IMDN or not)."=20 =20 3. In section 8.1.3 you refer to the requesting UAC in the feminine =20 " If a Requesting UAC wishes to keep her URI private through a B2BUA,..." =20 Although in the introduction section it is assumed that sender is masculine =20 " This document refers generically to the sender of a message in the masculine (he/him/his) and the recipient of the message in The feminine (she/her/hers)." =20 4.Why is there no Disposition value for "deleted" or "deleted without being read" instead of the "processed" being used for the case below? It seems like useful information and is a different information from the "processed" generated by a B2BUA and which does not really convey very precise information, since it is generated in cases of successful reception as well as cases of the B2BUA knowing that the final recipient cannot honour the IMDN request. =20 " If the UAS automatically deleted the message, or the user Deleted the message without reading it, then the UAS SHOULD generate a = processed IMDN, mindful of the privacy considerations enumerated in = Section 4." =20 5. In section 9.3.2, does the following recommendation apply to the UAS, the B2BUA or both??=20 "How long to keep the Message-ID state is a local matter. We RECOMMEND = it be at least 5 minutes."=20 =20 =20 Thanks, Nadia Bishai=20 =20 E-Mail: Nadia.Bishai@ericsson.com=20 Tel: (+1) 514-345-7900 8400 Decarie Boulevard=20 Cell: (+1) 514-591-6739 Montreal, Quebec, Canada=20 www.ericsson.com H4P-2N2 =20 -----Original Message----- From: Burger, Eric [mailto:eburger@brooktrout.com]=20 Sent: February 19, 2006 3:03 AM To: Simple WG Subject: [Simple] IMDN? There have been exactly zero comments on = draft-burger-simple-imdn-03.txt. I know there are many open issues. We were hoping to submit a work group draft -00. The deadline is = approaching. The open issues are still open. Does anyone care about IMDN? If no one reads the drafts or comments on = them, then the work is finished, in that the draft will expire and the = world will not have a standard mechanism for IM delivery reports. _______________________________________________ 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 Mar 02 10:06:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpNE-0004lQ-QZ; Thu, 02 Mar 2006 10:05:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpNC-0004jY-SO for simple@ietf.org; Thu, 02 Mar 2006 10:05:46 -0500 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEpNB-0001TK-D1 for simple@ietf.org; Thu, 02 Mar 2006 10:05:46 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id k22F5BnV015756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Mar 2006 16:05:11 +0100 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id k22F56Ui024156; Thu, 2 Mar 2006 16:05:06 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id k22F4phj024152; Thu, 2 Mar 2006 16:04:51 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-14.txt From: Hans Persson To: simple@ietf.org, ben@estacado.net, rohan@ekabal.com, fluffy@cisco.com In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Organization: Ingate Systems Date: Thu, 02 Mar 2006 16:04:50 +0100 Message-Id: <1141311890.13702.35.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Thu, 02 Mar 2006 16:05:11 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: 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: , Errors-To: simple-bounces@ietf.org m=E5n 2006-02-27 klockan 18:50 -0500 skrev Internet-Drafts@ietf.org: > Title : The Message Session Relay Protocol > Author(s) : B. Campbell, et al. > Filename : draft-ietf-simple-message-sessions-14.txt Questions: Section 4, SIP example: The Request-URIs in the INVITE and ACK messages are bob@atlanta.example.com while the To headers are bob@biloxi.example.com. Why are they not the same? Section 11.6, last paragraph on page 42: I don't understand the sentence "The client automatically sends the message over MSRPS to the two MSRP URIs involved." Where did MSRPS come from? Why not MSRP? Editorial consistency points: In some places the draft writes '"msrps" scheme', in others 'msrps: scheme' (with colon, without quotes), in yet others 'MSRPS schema'.=20 RFC references are sometimes written with capitals and sometimes without. Between "RFC" and the RFC number is sometimes a space, sometimes nothing, and sometimes "-". References to documents sometimes lack the space between the text and the bracketed reference number. Other editorial nits: Page 4, second last paragraph: Change "map this to a particular protocol to establish the session such as SIP." to "map this to a particular protocol, such as SIP, to establish the session." for better readability. Section 5.1, first paragraph: "boundary based" -> "boundary-based". Page 13, third paragraph: Spurious space in "re-INVITE ." Section 6, first line: "schema" -> "schemas". sixth paragraph: insert "that" after "indicates". seventh paragraph: "IANA registered" -> "IANA-registered". Page 17, second non-indented paragraph: insert "the" after "If". last paragraph: "MIME specific" -> "MIME-specific". Page 18, second last paragraph: "success Report" -> "success report". Section 7.1.1, last paragraph (page 20): insert "a" after "wants". Section 7.1.3, second paragraph: "implementation defined" -> "implementation-defined". Page 24, first non-indented paragraph: insert "that" after "assume". Section 7.3.2, last paragraph: "responses" -> "response". Section 8.1, last non-indented paragraph: " MUST," -> ", MUST". Section 10.2: insert "that" after "indicates". Section 10.3: ditto. Section 11.5: insert "http://" before "www". Section 11.6, second paragraph: "session mode" -> "session-mode". Section 13, last paragraph, first line: "are" -> "is". Section 14.3, first paragraph: "self signed" -> "self-signed". Page 49, first paragraph: "peer to peer" -> "peer-to-peer". third paragraph: "sip" -> "SIP", "identity header" -> "Identity header" (thrice). Section 14.4, first paragraph: "resource" -> "resources". Hans --=20 Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 02 13:43:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsle-0001hT-Us; Thu, 02 Mar 2006 13:43:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsld-0001hO-9p for simple@ietf.org; Thu, 02 Mar 2006 13:43:13 -0500 Received: from smtp5-g19.free.fr ([212.27.42.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEslc-00026j-Sa for simple@ietf.org; Thu, 02 Mar 2006 13:43:13 -0500 Received: from [192.168.0.3] (roo49-1-82-245-54-127.fbx.proxad.net [82.245.54.127]) by smtp5-g19.free.fr (Postfix) with ESMTP id AD3BE187D2; Thu, 2 Mar 2006 19:43:10 +0100 (CET) Message-ID: <44073CBF.4030105@laurentsteffan.com> Date: Thu, 02 Mar 2006 19:43:11 +0100 From: Laurent Steffan Organization: LAMSADE =?ISO-8859-15?Q?=28Universit=E9_de_Paris_Daup?= =?ISO-8859-15?Q?hine=29?= User-Agent: Mail/News 1.5 (X11/20060208) MIME-Version: 1.0 To: Simple WG Subject: Re: [Simple] IMDN? References: <330A23D8336C0346B5C1A5BB1966664702417F62@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702417F62@ATLANTIS.Brooktrout.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: "Burger, Eric" 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: , Errors-To: simple-bounces@ietf.org Hi Eric, Here are some comments on your draft. 1/ On the term Delivery: 1.a) you have in some places changed "Delivery" to "Disposition", but not consistently : for instance on page 5 (in the "Introduction") you state "This notification message is the Instant Message Disposition Notification (IMDN)" while the title, and elsewhere, says "Delivery". 1.b) While I do believe that reading of a message by a user is different form the protocol action called delivery, I also find that "Disposition" is not a very good term. Does it refer to "disposing *of*" a message ? not really, since the message is only handed over to the user who may then read it, delete it, have it processed by an automatic system, or do whatever else she wants ("she" being on the receiver side...). So what does it refer to ? Also, the term Disposition of a message may be used (e.g. in some RFCs) to describe the layout of a message, so that's misleading. I'd rather call the process you describe by another term: "Acceptance", perhaps (IM User Acceptance Notification ??? er...) OTOH, RFC 3798 makes a precedent, so I won't enter a lost battle... 2/ On the globally unique identifier : You state "A UAC MUST include a globally unique Message-ID. It is necessary for the Message-ID to be unique to the UAC in order for the UAC to be able to exactly correlate IMDN's with the messages they refer t= o". This is OK with me. However, part of your document describes conditions in which this uniqueness is not easily achievable, if at all : "Devices with limited resources and a high likelihood of total failure, such as a mobile phone, will lose their IMDN request state on total failu= re" so I wonder what will happen to the uniqueness of the Message-ID when such a device is reset : what's to prevent the device from reusing Message-IDs that it has already used ? of course I can envision deriving the Message-ID from the contents of the message (a hash function for instance) but is this practical for a device with "limited resources" ? In order to take care of that difficulty, you may want to change your MUST to a SHOULD. (OTOH, you may want to tell me where my reasoning is faulty, I wouldn't be too surprised...) Also, I think you should specify how the *globally unique* Message-ID is built : does it consist of a "device-identifier" + "local message identifier", for instance ? or is it derived from the message itself (see above) ? or random within a large space ? ... 3/ In 6.2.2, "processed" : You state that "the target URI of the message is a B2BUA", but that's not necessarily the case since in 9.2, "Recipient is the End User UAS", you say that "the UAS SHOULD generate a processed IMDN" 4/ "There are three broad categories of disposition states", but you actually name four. ;-) Besides, this is the only place where you speak of categories: perhaps you could just say "states" which is after all what you call them later. 5/ When you say "The 'read' state is straightforward", it seems a bit odd to find that "one cannot determine a priori the user actually read the message". Perhaps "displayed" might better capture your meaning. oh, and on the same page (3rd line from the top) you still have a reference to "deleted" from your previous draft. I think you might replace it with "processed". 6/ In section 8, you mix actions of the Requesting UAC with those of the B2BUA. I think for clarity it would be better to cleanly separate the protocol into "Requesting UAC Behaviour", "B2BUA Behaviour" (split from the current section 8) and "Reporting UAC Actions" (which already exists as section 9). OK, I'll stop there, sorry for the long post! Best regards, Laurent On 19.02.2006 09:03, Burger, Eric wrote: > There have been exactly zero comments on > draft-burger-simple-imdn-03.txt. I know there are many open issues. >=20 > We were hoping to submit a work group draft -00. The deadline is > approaching. The open issues are still open. >=20 > Does anyone care about IMDN? If no one reads the drafts or comments on= > them, then the work is finished, in that the draft will expire and the > world will not have a standard mechanism for IM delivery reports. --=20 Laurent Steffan LAMSADE (Universit=E9 Paris Dauphine) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 06 01:15:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG903-0005br-GV; Mon, 06 Mar 2006 01:15:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG902-0005bi-A1 for simple@ietf.org; Mon, 06 Mar 2006 01:15:18 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG8zy-0000fB-N5 for simple@ietf.org; Mon, 06 Mar 2006 01:15:18 -0500 Received: from [131.161.248.83] (open-131-161-248-83.cliq.com [131.161.248.83]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k266EtF22918; Sun, 5 Mar 2006 22:14:55 -0800 Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1464215691e5ccfda5d599bc79a0b42f@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Sun, 5 Mar 2006 22:07:15 -0800 To: "simple@ietf.org WG" X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Rohan Mahy Subject: [Simple] XCAP profile 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: , Errors-To: simple-bounces@ietf.org Hi, I just submitted an update to the XCAP profile draft. I took the advice of Henning, Robert, and several others from Vancouver to try to make this "profile" an optimization rather than anything else. Until it appears in the archive, you can find it here: http://scm.sipfoundry.org/rep/ietf-drafts/rohan/xcapalt/draft-mahy- simple-xcap-profile-01.html http://scm.sipfoundry.org/rep/ietf-drafts/rohan/xcapalt/draft-mahy- simple-xcap-profile-01.txt thanks, -rohan _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 06 02:26:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGA6b-0004op-P7; Mon, 06 Mar 2006 02:26:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGA6a-0004ok-E0 for simple@ietf.org; Mon, 06 Mar 2006 02:26:08 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGA6Y-00034r-Dy for simple@ietf.org; Mon, 06 Mar 2006 02:26:08 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 872154F0001; Mon, 6 Mar 2006 08:26:05 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 08:26:05 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 08:26:04 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D93D52369; Mon, 6 Mar 2006 09:26:04 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9991E1AB950; Mon, 6 Mar 2006 09:26:04 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 42FDF1AB91D; Mon, 6 Mar 2006 09:26:04 +0200 (EET) Subject: Re: [Simple]Question on MESSAGE From: "Salvatore Loreto (JO/LMF)" To: Michael Zhou In-Reply-To: <44029071.3080507@cisco.com> References: <4402885A.4010706@gmail.com> <44029071.3080507@cisco.com> Content-Type: text/plain Date: Mon, 06 Mar 2006 09:26:03 +0200 Message-Id: <1141629964.3479.4.camel@n121.nomadiclab.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 06 Mar 2006 07:26:05.0070 (UTC) FILETIME=[3A92D2E0:01C640EF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: simple-bounces@ietf.org On Mon, 2006-02-27 at 00:38 -0500, Michael Zhou wrote: > If you want to do session mode IM, then you need to establish the > session using INVITE and send IM inside the INVITE dialog. Microsoft > Mesenger implements session mode IM. a question about Mesenger implementation of session mode IM: how Mesenger keeps alive the session during an inactivity period ? does it leaves to expire the session and then reestablish it at the next message? /sal _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 06 06:06:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDXc-0003ds-C9; Mon, 06 Mar 2006 06:06:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDXb-0003dn-GJ for simple@ietf.org; Mon, 06 Mar 2006 06:06:15 -0500 Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGDXb-0004BK-0I for simple@ietf.org; Mon, 06 Mar 2006 06:06:15 -0500 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id k26B69No010388 for ; Mon, 6 Mar 2006 11:06:10 GMT (envelope-from Sean.Leahy@marconi.com) To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Sean Leahy" Date: Mon, 6 Mar 2006 11:06:09 +0000 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 06/03/2006 11:06:09, Serialize complete at 06/03/2006 11:06:09 X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: [Simple] Request URI of PUBLISH vs 'pres' URL of publishing entity 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="===============0582870515==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============0582870515== Content-Type: multipart/alternative; boundary="=_alternative 003CFCE180257129_=" This is a multipart message in MIME format. --=_alternative 003CFCE180257129_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There seems to be a contradiction within RFCs 3903, 3863 and=20 draft-rosenburg-simple-presence-processing-model-01. The Request-URI of a PUBLISH request contains the information necessary to = route the request to the Presence Server and identifies the resource whose = event state is to be published [RFC 3903]. Thus the PUBLISH request is=20 sent to the Presence Server that composes the presence state bound to the=20 address in the Request-URI. The presence element of a Presence Information Data Format document (PIDF) = [RFC 3863] must have an 'entity' attribute. The value of the 'entity'=20 attribute is the 'pres' URL of the presentity publishing this document.=20 i.e. the 'pres' URL appears to identify the publisher rather than the=20 subject of the presence document (these may or may not be the same). Is my understanding correct that the model allows for a separation of the=20 subject entity (identified by the Request-URI) and the publishing entity=20 (identified by the 'pres' URL)?=20 If so, I would have expected 'A Processing Model for Presence' (draft-rosen= burg-simple-presence-processing-model-01) to show that the collection of ev= ent state centres around the=20 Request-URI but in fact it identifies "the set of documents whose "entity" = attribute in the element in the presence document is the same=20 as that of the presentity." i.e. it appears to centre around the 'pres'=20 URL (in the PIDF in the PUBLISH request) rather than the Request-URI. This seems to contradict the position that the 'pres' URL identifies the=20 publisher rather than the subject of the presence document or at least=20 eliminates the idea that there is a separation of the subject entity=20 (identified by the Request-URI) and the publishing entity (identified by=20 the 'pres' URL). Please can you clarify which position is correct ?=20 If there is no separation between the subject and the publisher intended,=20 then can it be said the the Request URI of a PUBLISH request must always=20 be the same as the 'pres' URL (in the PIDF in the PUBLISH request) ? --=_alternative 003CFCE180257129_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
There seems to be a contradiction wi= thin RFCs 3903, 3863 and draft-rosenburg-simple-presence-processing-model-0= 1.

The Request-URI of a PUBLISH request= contains the information necessary to route the request to the Presence Se= rver and identifies the resource whose event state is to be published [RFC = 3903]. Thus the PUBLISH request is sent to the Presence Server that compose= s the presence state bound to the address in the Request-URI.

The presence element of a Presence I= nformation Data Format document (PIDF) [RFC 3863] must have an 'entity' att= ribute.  The value of the 'entity' attribute is the 'pres' URL of the = presentity publishing this document. i.e. the 'pres' URL appears to identif= y the publisher rather than the subject of the presence document (these may= or may not be the same).

Is my understanding correct that the= model allows for a separation of the subject entity (identified by the Req= uest-URI) and the publishing entity (identified by the 'pres' URL)?

If so, I would have expected 'A Proc= essing Model for Presence' (draft-rosenburg-simple-presence-processing-m= odel-01) to show that the collection of event state centres around the = Request-URI but in fact it identifies "the set of documents whose &quo= t;entity" attribute in the <presence> element in the presence do= cument is the same as that of the presentity." i.e. it appears to cent= re around the 'pres' URL (in the PIDF in the PUBLISH request) rather than t= he Request-URI.

This seems to contradict the positio= n that the 'pres' URL identifies the publisher rather than the subject of t= he presence document or at least eliminates the idea that there is a separa= tion of the subject entity (identified by the Request-URI) and the publishi= ng entity (identified by the 'pres' URL).

Please can you clarify which positio= n is correct ?

If there is no separation between th= e subject and the publisher intended, then can it be said the the Request U= RI of a PUBLISH request must always be the same as the  'pres' URL (in= the PIDF in the PUBLISH request)  ? --=_alternative 003CFCE180257129_=-- --===============0582870515== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0582870515==-- From simple-bounces@ietf.org Mon Mar 06 09:14:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGGTz-0001Qt-Eb; Mon, 06 Mar 2006 09:14:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGGTy-0001Qo-Lz for simple@ietf.org; Mon, 06 Mar 2006 09:14:42 -0500 Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGGTy-0003fv-4F for simple@ietf.org; Mon, 06 Mar 2006 09:14:42 -0500 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id k26EEZxm015607 for ; Mon, 6 Mar 2006 14:14:36 GMT (envelope-from Sean.Leahy@marconi.com) To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Sean Leahy" Date: Mon, 6 Mar 2006 14:14:39 +0000 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 06/03/2006 14:14:35, Serialize complete at 06/03/2006 14:14:35 X-Spam-Score: 0.3 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Subject: [Simple] Issue with comparisons for triggerring 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="===============1680003150==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============1680003150== Content-Type: multipart/alternative; boundary="=_alternative 004E3E9380257129_=" This is a multipart message in MIME format. --=_alternative 004E3E9380257129_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When considering the filtering of preferred information using 'triggers',=20 the child elements 'changed' ('from', 'to', and/or 'by'), 'added' or=20 'removed' refer to a comparison between current and previous XML=20 documents. The 'previous XML document' is 'the last XML document that was s= elected for delivery to that specific=20 subscription before any filter was applied to it' [draft-ietf-simple-filter= -format-05]. This requirement is self-contradictory. Although it implies that attention = is given to specific subscriptions during the comparison process, it=20 actually (and conversely) supports comparisons of versions on a per=20 presentity rather than on a per subscriber basis. Subscriber specific=20 versions are only created after filtering of the 'raw presence document'. T= he trigger that eventually determines=20 whether a document is delivered on a specific subscription is part of the=20 filter process that is excluded from the comparison.=20 e.g. when a trigger such as 'Status changed from value A to value C' is=20 specified but the Status changes in practice from value A to value B and=20 then again to value C. The result is that the document would not be=20 delivered when the Status changes to value C (the document that was=20 previously selected for delivery BEFORE any filter [e.g. current trigger] w= as applied had the Status value B ). The remedy is for the watcher to=20 set the trigger appropriate to what is required e.g. 'Status changed to=20 value C' rather than 'Status changed from value A to value C'. Another example is when a trigger such as 'changed by 2' is used and the=20 last value of the element / attribute was '6' but the element / attribute=20 actually changes to '7' then changes again to '8'. The result is that the=20 document would not be delivered when the value changes to 8 because it has = only changed by 1 with respect to the last (undelivered) version (the=20 document that was previously selected for delivery BEFORE any filter [e.g. = current trigger] was applied had the element / attribute value 7 ).=20 The results meet the formal requirement and also minimise the scalability=20 issues that would otherwise be associated with keeping previous versions=20 of notifications on every subscription that has a trigger active. However, = they may not meet the expectations of watchers that have interpreted the=20 requirement differently i.e. stressed "the last XML document that was=20 selected for delivery to that specific subscription" and ignored the fact=20 that "before any filter was applied to it" excludes the operation of the=20 trigger itself ! If the intention (contrary to the stated requirement) is that the presence = server must retain the last delivered set of information for every=20 subscription involving filters that include triggers, have the scalability = issues been considered ? Note: This problem does not affect the child elements 'added', 'removed'=20 or 'changed to', it only affects 'changed from to' and 'changed by' or to=20 put it another way it is the inclusion of support for 'changed from to'=20 and 'changed by' that creates the problem. Perhaps, support = for these particular combinations of child elements should at least be=20 optional ? --=_alternative 004E3E9380257129_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
When considering the filtering of pr= eferred information using 'triggers', the child elements 'changed' ('from',= 'to', and/or 'by'), 'added' or 'removed' refer to a comparison between cur= rent and previous XML documents. The 'previous XML document' is 'the= last XML document that was selected for delivery to that specific subscrip= tion before any filter was applied to it' [draft-ietf-simple-= filter-format-05].

This requirement is self-contradicto= ry. Although it implies that attention is given to specific subscriptions d= uring the comparison process, it actually (and conversely) supports compari= sons of versions on a per presentity rather than on a per subscriber basis.=  Subscriber specific versions are only created after filtering= of the 'raw presence document'. The trigger that eventually determines whe= ther a document is delivered on a specific subscription is part of the filt= er process that is excluded from the comparison.

e.g. when a trigger such as 'Status = changed from value A to value C' is specified but the Status changes in pra= ctice from value A to value B and then again to value C. The result is that= the document would not be delivered when the Status changes to value C (th= e document that was previously selected for delivery BEFORE any filter [= e.g. current trigger] was applied had the Status value B ). The remedy = is for the watcher to set the trigger appropriate to what is required e.g. = 'Status changed to value C' rather than  'Status changed from value A = to value C'.

Another example is when a trigger su= ch as 'changed by 2' is used and the last value of the element / attribute = was '6' but the element / attribute actually changes to '7' then changes ag= ain to '8'. The result is that the document would not be delivered when the= value changes to 8 because it has only changed by 1 with respect to the la= st (undelivered) version (the document that was previously selected for del= ivery BEFORE any filter [e.g. current trigger] was applied had the e= lement / attribute value 7 ).

The results meet the formal requirem= ent and also minimise the scalability issues that would otherwise be associ= ated with keeping previous versions of notifications on every subscription = that has a trigger active. However, they may not meet the expectations of w= atchers that have interpreted the requirement differently i.e. stressed &qu= ot;the last XML document that was selected for delivery to that specific su= bscription" and ignored the fact that "before any filter was appl= ied to it" excludes the operation of the trigger itself !

If the intention (contrary to the st= ated requirement) is that the presence server must retain the last delivere= d set of information for every subscription involving filters that include = triggers, have the scalability issues been considered ?

Note: This problem does not affect &= nbsp;the child elements 'added', 'removed' or 'changed to', it only affects= 'changed from to' and 'changed by' or to put it another way it is the incl= usion of support for  'changed from to' and 'changed by' that creates = the <scaleability> problem. Perhaps, support for these particular com= binations of child elements should at least be optional ? --=_alternative 004E3E9380257129_=-- --===============1680003150== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1680003150==-- From simple-bounces@ietf.org Mon Mar 06 11:20:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGIRW-0005pL-0j; Mon, 06 Mar 2006 11:20:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGIRR-0005kf-Gt for simple@ietf.org; Mon, 06 Mar 2006 11:20:13 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGIRQ-00005P-RS for simple@ietf.org; Mon, 06 Mar 2006 11:20:13 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 613DA19447B for ; Mon, 6 Mar 2006 17:20:11 +0100 (CET) Received: from [192.168.1.77] ([192.168.1.77]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 17:18:38 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Simple] Issue with comparisons for triggerring Date: Mon, 6 Mar 2006 17:20:32 +0100 To: "Sean Leahy" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 06 Mar 2006 16:18:38.0293 (UTC) FILETIME=[A02DB850:01C64139] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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: , Errors-To: simple-bounces@ietf.org On Mar 6, 2006, at 3:14 PM, Sean Leahy wrote: > > When considering the filtering of preferred information using=20 > 'triggers', the child elements 'changed' ('from', 'to', and/or 'by'),=20= > 'added' or 'removed' refer to a comparison between current and=20 > previous XML documents. The 'previous XML document' is 'the last XML=20= > document that was selected for delivery to that specific subscription=20= > before any filter was applied to it'=20 > [draft-ietf-simple-filter-format-05]. You are making a false assumption about the above quoted sentence.=20 Nothing in that sentence says that the XML document was not sent. But=20 if you misread it that way, then I guess it needs rephrasing. > > > This requirement is self-contradictory. Although it implies that=20 > attention is given to specific subscriptions during the comparison=20 > process, it actually (and conversely) supports comparisons of versions=20= > on a per presentity rather than on a per subscriber basis. =A0Subscriber= =20 > specific versions are only created after filtering of the 'raw=20 > presence document'. The trigger that eventually determines whether a=20= > document is delivered on a specific subscription is part of the filter=20= > process that is excluded from the comparison. > > e.g. when a trigger such as 'Status changed from value A to value C'=20= > is specified but the Status changes in practice from value A to value=20= > B and then again to value C. The result is that the document would not=20= > be delivered when the Status changes to value C (the document that was=20= > previously selected for delivery BEFORE any filter [e.g. current=20 > trigger] was applied had the Status value B ). The remedy is for the=20= > watcher to set the trigger appropriate to what is required e.g.=20 > 'Status changed to value C' rather than =A0'Status changed from value = A=20 > to value C'. > > Another example is when a trigger such as 'changed by 2' is used and=20= > the last value of the element / attribute was '6' but the element /=20 > attribute actually changes to '7' then changes again to '8'. The=20 > result is that the document would not be delivered when the value=20 > changes to 8 because it has only changed by 1 with respect to the last=20= > (undelivered) version (the document that was previously selected for=20= > delivery BEFORE any filter [e.g. current trigger] was applied had the=20= > element / attribute value 7 ). > > The results meet the formal requirement and also minimise the=20 > scalability issues that would otherwise be associated with keeping=20 > previous versions of notifications on every subscription that has a=20 > trigger active. However, they may not meet the expectations of=20 > watchers that have interpreted the requirement differently i.e.=20 > stressed "the last XML document that was selected for delivery to that=20= > specific subscription" and ignored the fact that "before any filter=20 > was applied to it" excludes the operation of the trigger itself ! > > If the intention (contrary to the stated requirement) is that the=20 > presence server must retain the last delivered set of information for=20= > every subscription involving filters that include triggers, have the=20= > scalability issues been considered ? Why is there a scalability issue? Since you only need to retain a copy=20= of the last sent XML document to the subscriber *before filtering is=20 applied*, my guess is that it will be the same for all it was sent to.=20= You just need to mark it with something that indicates who received it.=20= I don't think that will cause scalability issues. Regards, Hisham > > Note: This problem does not affect =A0the child elements 'added',=20 > 'removed' or 'changed to', it only affects 'changed from to' and=20 > 'changed by' or to put it another way it is the inclusion of support=20= > for =A0'changed from to' and 'changed by' that creates the=20 > problem. Perhaps, support for these particular=20 > combinations of child elements should at least be optional=20 > ?_______________________________________________ > 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 Mar 07 07:38:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGbSc-00029k-9C; Tue, 07 Mar 2006 07:38:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGbSb-000279-Ax for simple@ietf.org; Tue, 07 Mar 2006 07:38:41 -0500 Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGbSa-0000pS-Dj for simple@ietf.org; Tue, 07 Mar 2006 07:38:41 -0500 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id k278DSVo001223; Tue, 7 Mar 2006 12:38:27 GMT (envelope-from Sean.Leahy@marconi.com) To: "Hisham Khartabil Subject: Re: [Simple] Issue with comparisons for triggerring MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Sean Leahy" Date: Tue, 7 Mar 2006 09:42:20 +0000 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 07/03/2006 12:38:31, Serialize complete at 07/03/2006 12:38:31 X-Spam-Score: 0.1 (/) X-Scan-Signature: efb5d987e2484f3d9a304cc31a003441 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: , Content-Type: multipart/mixed; boundary="===============1232668820==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============1232668820== Content-Type: multipart/alternative; boundary="=_alternative 003550978025712A_=" This is a multipart message in MIME format. --=_alternative 003550978025712A_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hisham and others, Please see in-line comments attached below marked 'Sean March 7': Regards, Sean Hisham Khartabil 06/03/2006 16:20 =20 To: "Sean Leahy" cc: simple@ietf.org Subject: Re: [Simple] Issue with comparisons for triggerring On Mar 6, 2006, at 3:14 PM, Sean Leahy wrote: Sean March 6 > When considering the filtering of preferred information using=20 > 'triggers', the child elements 'changed' ('from', 'to', and/or 'by'),=20 > 'added' or 'removed' refer to a comparison between current and=20 > previous XML documents. The 'previous XML document' is 'the last XML=20 > document that was selected for delivery to that specific subscription=20 > before any filter was applied to it'=20 > [draft-ietf-simple-filter-format-05]. Hisham March 6 You are making a false assumption about the above quoted sentence.=20 Nothing in that sentence says that the XML document was not sent.=20 But if you misread it that way, then I guess it needs rephrasing. Sean March 7=20 I think my point has been missed or I was not clear enough. I am not=20 making an assumption that the XML document was not sent rather I am obeying the requirement that the comparison is with the last XML=20 document "selected for delivery to that specific subscription before=20 any filter was applied to it." This necessarily implies that the=20 trigger that determines whether a document is delivered or not is part=20 of the filter process that determines it MAY not be sent. Sean March 7=20 In particular, in the cases of the examples given previously ,=20 where the trigger uses the child elements 'changed from to' or=20 'changed by', if there is a value that occurs in practice in between=20 the wanted values then the document WILL not be sent precisely because=20 of the operation of the trigger itself. The trigger occurs within the=20 scope of filtering i.e. after the comparison of XML Documents according=20 to the definition in draft-ietf-simple-filter-format-05. Sean March 7 In my example, a trigger is 'Status changed from value A to value C'=20 but the Status changes in practice from A to B and then again to C. The=20 result is that the document would not be delivered when the Status changes = from A to B nor when the document changes from B to C. The document that=20 is 'selected for delivery to that specific subscription before any filter=20 was applied to it' (i.e. before the operation of the trigger within the=20 filter for preferred information) never changes from value A to value C. It only changes from A to C when it is the filtered documents rather than the unfiltered documents that are compared. Thus if it was desired to take this into account, the requirement would have to change to: "...The 'previous XML document' is 'the last XML document that was=20 selected=20 for delivery to that specific subscription AFTER any filter was applied to = it'=20 Sean March 6 > This requirement is self-contradictory. Although it implies that=20 > attention is given to specific subscriptions during the comparison=20 > process, it actually (and conversely) supports comparisons of versions=20 > on a per presentity rather than on a per subscriber basis. =A0Subscriber = > specific versions are only created after filtering of the 'raw=20 > presence document'. The trigger that eventually determines whether a=20 > document is delivered on a specific subscription is part of the filter=20 > process that is excluded from the comparison. > > e.g. when a trigger such as 'Status changed from value A to value C'=20 > is specified but the Status changes in practice from value A to value=20 > B and then again to value C. The result is that the document would not=20 > be delivered when the Status changes to value C (the document that was=20 > previously selected for delivery BEFORE any filter [e.g. current=20 > trigger] was applied had the Status value B ). The remedy is for the=20 > watcher to set the trigger appropriate to what is required e.g.=20 > 'Status changed to value C' rather than =A0'Status changed from value A=20 > to value C'. > > Another example is when a trigger such as 'changed by 2' is used and=20 > the last value of the element / attribute was '6' but the element /=20 > attribute actually changes to '7' then changes again to '8'. The=20 > result is that the document would not be delivered when the value=20 > changes to 8 because it has only changed by 1 with respect to the last=20 > (undelivered) version (the document that was previously selected for=20 > delivery BEFORE any filter [e.g. current trigger] was applied had the=20 > element / attribute value 7 ). > > The results meet the formal requirement and also minimise the=20 > scalability issues that would otherwise be associated with keeping=20 > previous versions of notifications on every subscription that has a=20 > trigger active. However, they may not meet the expectations of=20 > watchers that have interpreted the requirement differently i.e.=20 > stressed "the last XML document that was selected for delivery to that=20 > specific subscription" and ignored the fact that "before any filter=20 > was applied to it" excludes the operation of the trigger itself ! > > If the intention (contrary to the stated requirement) is that the=20 > presence server must retain the last delivered set of information for=20 > every subscription involving filters that include triggers, have the=20 > scalability issues been considered ? Hisham March 6 Why is there a scalability issue? Since you only need to retain a copy=20 of the last sent XML document to the subscriber *before filtering is=20 applied*, my guess is that it will be the same for all it was sent to.=20 You just need to mark it with something that indicates who received it.=20 I don't think that will cause scalability issues. Sean March 7 See my previous comment of March 7 (above). In fact, it would be necessary to retain a copy of the last sent XML document AFTER filtering for=20 preferred information (including triggers) is applied per subscription. This XML=20 document would differ between subscriptions that invoked different=20 triggers=20 and it is simply not good enough to assume it would be the same for all.=20 Marking an unfiltered document to indicate who receives it is inadequate=20 because the same unfilterred document can result in many different=20 filtered=20 documents that are received by different watchers. Regards, Hisham > > Note: This problem does not affect =A0the child elements 'added',=20 > 'removed' or 'changed to', it only affects 'changed from to' and=20 > 'changed by' or to put it another way it is the inclusion of support=20 > for =A0'changed from to' and 'changed by' that creates the=20 > problem. Perhaps, support for these particular=20 > combinations of child elements should at least be optional=20 > ?=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple --=_alternative 003550978025712A_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hisham and others,

Please see in-line comments attached= below marked 'Sean March 7':

Regards,
Sean



Hisham Khartabil <hisham.khart= abil@telio.no>

06/03/2006 16:20

       
        To: &nbs= p;      "Sean Leahy" <Sean.Leahy@marconi.com>= ;
        cc: &nbs= p;      simple@ietf.org
        Subject:=        Re: [Simple] Issue with comparisons for trigger= ring




On Mar 6, 2006, at 3:14 PM, Sean Leahy wrote:

Sean March 6
> When considering the filtering= of preferred information using
> 'triggers', the child elements 'changed' ('from', 'to', and/or 'by'), =
> 'added' or 'removed' refer to a comparison between current and
> previous XML documents. The 'previous XML document' is 'the last XML <= br> > document that was selected for delivery to that specific subscription =
> before any filter was applied to it'
> [draft-ietf-simple-filter-format-05].

Hisham March 6
You are making a false assumption a= bout the above quoted sentence.
Nothing in that sentence says that the XML document was not sent.
But if you misread it that way, the= n I guess it needs rephrasing.

Sean March 7
I think my point has been missed or= I was not clear enough. I am not
making an assumption that the XML d= ocument was not sent rather I am
obeying the requirement that the co= mparison is with the last XML
document "selected for deliver= y to that specific subscription before
any filter was applied to it."= This necessarily implies that the
trigger that determines whether a d= ocument is delivered or not is part
of the filter process that <subs= equently> determines it MAY not be sent.

Sean March 7
In particular, in the cases of the = examples given previously <below>,
where the trigger uses the child el= ements 'changed from to' or
'changed by', if there is a value t= hat occurs in practice in between
the wanted values then the document= WILL not be sent precisely because
of the operation of the trigger its= elf. The trigger occurs within the
scope of filtering i.e. after the c= omparison of XML Documents according
to the definition in draft-ietf-sim= ple-filter-format-05.

Sean March 7
In my example, a trigger is 'Status= changed from value A to value C'
but the Status changes in practice from A to B and then again to C. The
result is that the document would n= ot be delivered when the Status changes
from A to B nor when the document c= hanges from B to C. The document that
is 'selected for delivery to that s= pecific subscription before any filter
was applied to it' (i.e. before the= operation of the trigger within the
filter for preferred information) n= ever changes from value A to value C.
It only changes from A to C when it= is the filtered documents rather than
the unfiltered documents that are c= ompared. Thus if it was desired to take
this into account, the requirement = would have to change to:
"...The 'previous XML document= ' is 'the last XML document that was selected
for delivery to that specific subsc= ription AFTER any filter was applied to it'

Sean March 6
> This requirement is self-contradictory. Although it implies that
> attention is given to specific subscriptions during the comparison
> process, it actually (and conversely) supports comparisons of versions=
> on a per presentity rather than on a per subscriber basis. =A0Subscrib= er
> specific versions are only created after filtering of the 'raw
> presence document'. The trigger that eventually determines whether a <= br> > document is delivered on a specific subscription is part of the filter=
> process that is excluded from the comparison.
>
> e.g. when a trigger such as 'Status changed from value A to value C' <= br> > is specified but the Status changes in practice from value A to value =
> B and then again to value C. The result is that the document would not=
> be delivered when the Status changes to value C (the document that was=
> previously selected for delivery BEFORE any filter [e.g. current
> trigger] was applied had the Status value B ). The remedy is for the <= br> > watcher to set the trigger appropriate to what is required e.g.
> 'Status changed to value C' rather than =A0'Status changed from value = A
> to value C'.
>
> Another example is when a trigger such as 'changed by 2' is used and <= br> > the last value of the element / attribute was '6' but the element / > attribute actually changes to '7' then changes again to '8'. The
> result is that the document would not be delivered when the value
> changes to 8 because it has only changed by 1 with respect to the last=
> (undelivered) version (the document that was previously selected for <= br> > delivery BEFORE any filter [e.g. current trigger] was applied had the =
> element / attribute value 7 ).
>
> The results meet the formal requirement and also minimise the
> scalability issues that would otherwise be associated with keeping
> previous versions of notifications on every subscription that has a > trigger active. However, they may not meet the expectations of
> watchers that have interpreted the requirement differently i.e.
> stressed "the last XML document that was selected for delivery to= that
> specific subscription" and ignored the fact that "before any= filter
> was applied to it" excludes the operation of the trigger itself !=
>
> If the intention (contrary to the stated requirement) is that the
> presence server must retain the last delivered set of information for =
> every subscription involving filters that include triggers, have the <= br> > scalability issues been considered ?

Hisham March 6
Why is there a scalability issue? S= ince you only need to retain a copy
of the last sent XML document to the subscriber *before filtering is
applied*, my guess is that it will be the same for all it was sent to.
You just need to mark it with something that indicates who received it.
I don't think that will cause scalability issues.

Sean March 7
See my previous comment of March 7 = (above). In fact, it would be necessary
to retain a copy of the last sent X= ML document AFTER filtering for preferred
information (including triggers) is= applied per subscription. This XML
document would differ between subsc= riptions that invoked different triggers
and it is simply not good enough to= assume it would be the same for all.
Marking an unfiltered document to i= ndicate who receives it is inadequate
because the same unfilterred docume= nt can result in many different filtered
documents that are received by diff= erent watchers.

Regards,
Hisham


>
> Note: This problem does not affect =A0the child elements 'added',
> 'removed' or 'changed to', it only affects 'changed from to' and
> 'changed by' or to put it another way it is the inclusion of support <= br> > for =A0'changed from to' and 'changed by' that creates the
> <scaleability> problem. Perhaps, support for these particular > combinations of child elements should at least be optional
> ?=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple

--=_alternative 003550978025712A_=-- --===============1232668820== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1232668820==-- From simple-bounces@ietf.org Tue Mar 07 11:54:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfRl-0006gv-9m; Tue, 07 Mar 2006 11:54:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfRk-0006fk-NL for simple@ietf.org; Tue, 07 Mar 2006 11:54:04 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGfRj-0001jB-PT for simple@ietf.org; Tue, 07 Mar 2006 11:54:04 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 2ABAC19445E for ; Tue, 7 Mar 2006 17:54:02 +0100 (CET) Received: from [192.168.1.72] ([192.168.1.72]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 17:52:28 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Simple] Issue with comparisons for triggerring Date: Tue, 7 Mar 2006 17:54:27 +0100 To: "Sean Leahy" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 07 Mar 2006 16:52:28.0644 (UTC) FILETIME=[84C67240:01C64207] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 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: , Errors-To: simple-bounces@ietf.org On Mar 7, 2006, at 10:42 AM, Sean Leahy wrote: > > Hisham and others, > > Please see in-line comments attached below marked 'Sean March 7': > > Regards, > Sean > > > > Hisham Khartabil > > 06/03/2006 16:20 > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0"Sean Leahy" = > =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0simple@ietf.org > =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0Re: [Simple] Issue with = comparisons for=20 > triggerring > > > > > On Mar 6, 2006, at 3:14 PM, Sean Leahy wrote: > > Sean March 6 > > When considering the filtering of preferred information using > > 'triggers', the child elements 'changed' ('from', 'to', and/or=20 > 'by'), > > 'added' or 'removed' refer to a comparison between current and > > previous XML documents. The 'previous XML document' is 'the last = XML > > document that was selected for delivery to that specific=20 > subscription > > before any filter was applied to it' > > [draft-ietf-simple-filter-format-05]. > > Hisham March 6 > You are making a false assumption about the above quoted sentence. > Nothing in that sentence says that the XML document was not sent. > But if you misread it that way, then I guess it needs rephrasing. > > Sean March 7 > I think my point has been missed or I was not clear enough. I am not > making an assumption that the XML document was not sent rather I am > obeying the requirement that the comparison is with the last XML > document "selected for delivery to that specific subscription before > any filter was applied to it." This necessarily implies that the > trigger that determines whether a document is delivered or not is part > of the filter process that determines it MAY not be=20 > sent. Perhaps rephrasing the sentence to say the following will help you=20 understand why I meant with my response. The 'previous XML documen' is "the last XML document that was selected=20= for delivery to that specific subscription before any filter was=20 applied to it and where the XML document was subsequently delivered,=20 after filtering, to the subscriber" What I'm trying to say is that the filters for triggers are used by=20 comparing the current XML document with the XML document that was most=20= recently sent to the subscriber, but before the filters were applied to=20= it. > > Sean March 7 > In particular, in the cases of the examples given previously , > where the trigger uses the child elements 'changed from to' or > 'changed by', if there is a value that occurs in practice in between > the wanted values then the document WILL not be sent precisely because > of the operation of the trigger itself. The trigger occurs within the > scope of filtering i.e. after the comparison of XML Documents = according > to the definition in draft-ietf-simple-filter-format-05. > > Sean March 7 > In my example, a trigger is 'Status changed from value A to value C' > but the Status changes in practice from A to B and then again to C.=20= > The > result is that the document would not be delivered when the Status=20 > changes > from A to B nor when the document changes from B to C. The document=20 > that > is 'selected for delivery to that specific subscription before any=20 > filter > was applied to it' (i.e. before the operation of the trigger within = the > filter for preferred information) never changes from value A to value=20= > C. > It only changes from A to C when it is the filtered documents rather=20= > than > the unfiltered documents that are compared. Thus if it was desired to=20= > take > this into account, the requirement would have to change to: > "...The 'previous XML document' is 'the last XML document that was=20 > selected > for delivery to that specific subscription AFTER any filter was=20 > applied to it' > > Sean March 6 > > This requirement is self-contradictory. Although it implies that > > attention is given to specific subscriptions during the comparison > > process, it actually (and conversely) supports comparisons of=20 > versions > > on a per presentity rather than on a per subscriber basis.=20 > =A0Subscriber > > specific versions are only created after filtering of the 'raw > > presence document'. The trigger that eventually determines whether = a > > document is delivered on a specific subscription is part of the=20 > filter > > process that is excluded from the comparison. > > > > e.g. when a trigger such as 'Status changed from value A to value = C' > > is specified but the Status changes in practice from value A to=20 > value > > B and then again to value C. The result is that the document would=20= > not > > be delivered when the Status changes to value C (the document that=20= > was > > previously selected for delivery BEFORE any filter [e.g. current > > trigger] was applied had the Status value B ). The remedy is for = the > > watcher to set the trigger appropriate to what is required e.g. > > 'Status changed to value C' rather than =A0'Status changed from = value=20 > A > > to value C'. > > > > Another example is when a trigger such as 'changed by 2' is used = and > > the last value of the element / attribute was '6' but the element / > > attribute actually changes to '7' then changes again to '8'. The > > result is that the document would not be delivered when the value > > changes to 8 because it has only changed by 1 with respect to the=20= > last > > (undelivered) version (the document that was previously selected = for > > delivery BEFORE any filter [e.g. current trigger] was applied had=20= > the > > element / attribute value 7 ). > > > > The results meet the formal requirement and also minimise the > > scalability issues that would otherwise be associated with keeping > > previous versions of notifications on every subscription that has a > > trigger active. However, they may not meet the expectations of > > watchers that have interpreted the requirement differently i.e. > > stressed "the last XML document that was selected for delivery to=20= > that > > specific subscription" and ignored the fact that "before any filter > > was applied to it" excludes the operation of the trigger itself ! > > > > If the intention (contrary to the stated requirement) is that the > > presence server must retain the last delivered set of information=20= > for > > every subscription involving filters that include triggers, have = the > > scalability issues been considered ? > > Hisham March 6 > Why is there a scalability issue? Since you only need to retain a copy > of the last sent XML document to the subscriber *before filtering is > applied*, my guess is that it will be the same for all it was sent = to. > You just need to mark it with something that indicates who received=20= > it. > I don't think that will cause scalability issues. > > Sean March 7 > See my previous comment of March 7 (above). In fact, it would be=20 > necessary > to retain a copy of the last sent XML document AFTER filtering for=20 > preferred > information (including triggers) is applied per subscription. I don't understand why you need the xml document AFTER filtering. > This XML > document would differ between subscriptions that invoked different=20 > triggers > and it is simply not good enough to assume it would be the same for=20 > all. > Marking an unfiltered document to indicate who receives it is=20 > inadequate > because the same unfilterred document can result in many different=20 > filtered > documents that are received by different watchers. Yes, but that is the one you need to apply the filter to. I don't=20 understand how you can compare 2 xml documents where one is filtered=20 and the other is not. Hisham > > Regards, > Hisham > > > > > > Note: This problem does not affect =A0the child elements 'added', > > 'removed' or 'changed to', it only affects 'changed from to' and > > 'changed by' or to put it another way it is the inclusion of = support > > for =A0'changed from to' and 'changed by' that creates the > > problem. Perhaps, support for these particular > > combinations of child elements should at least be optional > > ?_______________________________________________ > > 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 Mar 07 17:34:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGkku-0007yP-HG; Tue, 07 Mar 2006 17:34:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGkkt-0007vo-4p; Tue, 07 Mar 2006 17:34:11 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGkkr-0006R6-QF; Tue, 07 Mar 2006 17:34:11 -0500 Received: from [172.17.2.252] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k27MY1nV048617 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 7 Mar 2006 16:34:02 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <0B23EA50-279C-4548-B7F1-4CB334ABF93E@nostrum.com> References: <0B23EA50-279C-4548-B7F1-4CB334ABF93E@nostrum.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <737A9826-2F96-4F1C-95D6-4AEA17F9DB2E@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Tue, 7 Mar 2006 16:34:00 -0600 To: Robert Sparks X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (shaman.nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "sip@ietf.org WG" , sip-implementors@cs.columbia.edu, Sipping WG , "simple@ietf.org list" Subject: [Simple] Re: [Sip] SIPIT 18 Registration 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: , Errors-To: simple-bounces@ietf.org Reminder: Registration for SIPIT 18 closes in 3 weeks. If you are planning to attend and have not yet registered, please do so now. Thanks, RjS On Feb 6, 2006, at 11:42 PM, Robert Sparks wrote: > Registration for SIPit 18 is open. > > This event will be held April 17-21 in > Akihabara, Tokyo, Japan. More information > about the event is available at http://www.sipit.net > and the host website at http://www.nic.ad.jp/en/sipit18/ > > Registration will close March 31. Please register early. > You can register now using https://www.regonline.com/88905 > > This 18th SIPForum SIPit is > > Hosted by: > - Japan Network Information Center (JPNIC) > > Co-hosted by: > - WIDE Project > - VoIP System Interoperability Task Force > > Supported by: > - Ministry of Internal Affairs and Communications (MIC) > - The Telecommunication Technology Committee (TTC) > - Telecom Service Association (TELESA) > - VoIP Forum Japan (VFJ) > - IPv6 Promotion Council (v6PC) > - ENUM Trial Japan (ETJP) > > Sponsors: > - Cisco Systems, Inc. > - Fractalist Inc. > - Fusion Communications Corporation > - Japan Telecom Co., Ltd. > - KDDI Corporation > - Mitsubishi Electric Information Network Corporation > - Mitsubishi Research Institute, Inc. > - NEC Corporation > - Netmarks Inc. > - Nippon Telegraph and Telephone Corporation > - Nippon Telegraph and Telephone East Corporation > - Nippon Telegraph and Telephone West Corporation > - NTT Advanced Technology Corporation > - Oki Electric Industry Co., Ltd. > - SoftBank BB Corp. > - Softfront > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 08 06:33:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGwuv-00017K-Ha; Wed, 08 Mar 2006 06:33:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGwut-00015G-Ub for simple@ietf.org; Wed, 08 Mar 2006 06:33:19 -0500 Received: from smtp3.infineon.com ([203.126.106.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGwus-0005nv-FS for simple@ietf.org; Wed, 08 Mar 2006 06:33:19 -0500 Received: from unknown (HELO sinse211.ap.infineon.com) ([172.17.65.149]) by smtp3.infineon.com with ESMTP; 08 Mar 2006 19:33:15 +0800 X-SBRS: None Received: from blrse201.ap.infineon.com ([172.20.20.12]) by sinse211.ap.infineon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Mar 2006 19:33:15 +0800 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Mar 2006 17:03:14 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple MSRP Session Thread-Index: AcZCpBXuvA+nR5aET8yd46kUMntcfw== From: To: , X-OriginalArrivalTime: 08 Mar 2006 11:33:15.0646 (UTC) FILETIME=[171CA1E0:01C642A4] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Simple] Multiple MSRP Session 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: , Errors-To: simple-bounces@ietf.org Hi All, I am just wondering how can we create multiple MSRP sessions between same users? (MSRP Draft is talking about sharing the same TCP connection which implied multiple MSRP sessions between same users). How does the connection establishment happen?=20 First Session we can create sending SIP invite and negotiating the MSRP URL in SDP offer/answer. Now with the same SIP session how can we create another MSRP session?=20 Any scenario, which defines sharing the same TCP connection between multiple MSRP sessions, along with some details/call flow for session establishment will be appreciated . Regards, Amit Kumar Goel Infineon Technology, 11th Floor, Discoverer Building, Whitefield,ITPL, Bangalore-560066 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 08 06:57:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGxIK-0006Ik-En; Wed, 08 Mar 2006 06:57:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGxII-0006GB-IK for simple@ietf.org; Wed, 08 Mar 2006 06:57:30 -0500 Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGxIH-0006N0-8n for simple@ietf.org; Wed, 08 Mar 2006 06:57:30 -0500 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id k289rp7k002475; Wed, 8 Mar 2006 11:56:53 GMT (envelope-from Sean.Leahy@marconi.com) To: "Hisham Khartabil Subject: Re: [Simple] Issue with comparisons for triggerring MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Sean Leahy" Date: Wed, 8 Mar 2006 09:48:15 +0000 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 08/03/2006 11:56:16, Serialize complete at 08/03/2006 11:56:16 X-Spam-Score: 0.5 (/) X-Scan-Signature: 320ddee61cb2d39f489e9191ae3fdc8c 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: , Content-Type: multipart/mixed; boundary="===============0239799436==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============0239799436== Content-Type: multipart/alternative; boundary="=_alternative 0035DB728025712B_=" This is a multipart message in MIME format. --=_alternative 0035DB728025712B_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hisham Khartabil wrote: "Perhaps rephrasing the sentence to say the following will help you=20 understand why I meant with my response. The 'previous XML documen' is "the last XML document that was selected=20 for delivery to that specific subscription before any filter was=20 applied to it and where the XML document was subsequently delivered,=20 after filtering, to the subscriber" What I'm trying to say is that the filters for triggers are used by=20 comparing the current XML document with the XML document that was most=20 recently sent to the subscriber, but before the filters were applied to=20 it." Sean Leahy> So "the last XML document that was selected=20 for delivery to that specific subscription before any filter was=20 applied to it" could be where the Status changed from 'A' to 'B' - this did not meet the criterion that it "was subsequently delivered,=20 after filtering, to the subscriber" (because the trigger is from 'A' to=20 'C'). Sean Leahy> So now we have to look further back for the document that=20 was the "the next last XML document that was selected=20 for delivery to that specific subscription before any filter was=20 applied to it" - this could be where the Status was marked as 'A'. i.e. it = is the original document that was sent to the watcher in that case this doc=20 meets both the criteria. Sean Leahy> However, in the case that it also was not sent, we have to=20 look further back again. Sean Leahy> Each subscription may have to go back to a different original=20 unfiltered document. e.g. Presentity =3D Fred Document Fred F last sent to Watchers A, G,=20 Document Fred E last sent to WatchersB , H Document Fred D last sent to Watchers C, K, R Document Fred C last sent to Watcher D, P, Document Fred B last sent to Watcher E, M Document Fred A last sent to Watcher F How many versions of Fred's unfiltered presence document do we need to=20 keep ? This depends on the number of subscriptions and the triggers operating on=20 each subscription. Is this the intention ? This seems to introduce a scalability problem. Note: It is the inclusion of support for =A0'changed from to' and 'changed = by' that creates the problem. Perhaps, support for these particular combinations = of child elements=20 should at least be optional. Hisham Khartabil wrote: Yes, but that [the last sent XML document to the subscriber before filterin= g is applied-my addition] is the one you need to apply the filter to. I don't=20 understand how you can compare 2 xml documents where one is filtered=20 and the other is not. Sean Leahy> I never proposed this. I suggested we either compare 2=20 filtered documents together or 2 unfiltered documents together and=20 believed the original requirement was unclear which was the case. It appeared to=20 specify on the one hand that unfiltered documents were compared (thus ignoring the=20 operation of the trigger in the past in determining what was delivered) and on the other=20 hand that it was filtered documents that were compared (taking account of what was=20 delivered on each subscription). Regards, Sean Hisham Khartabil 07/03/2006 16:54 =20 To: "Sean Leahy" cc: simple@ietf.org Subject: Re: [Simple] Issue with comparisons for triggerring On Mar 7, 2006, at 10:42 AM, Sean Leahy wrote: > > Hisham and others, > > Please see in-line comments attached below marked 'Sean March 7': > > Regards, > Sean > > > > Hisham Khartabil > > 06/03/2006 16:20 > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0"Sean Leahy" > =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0simple@ietf.org > =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0Re: [Simple] Issue with compariso= ns for=20 > triggerring > > > > > On Mar 6, 2006, at 3:14 PM, Sean Leahy wrote: > > Sean March 6 > > When considering the filtering of preferred information using > > 'triggers', the child elements 'changed' ('from', 'to', and/or=20 > 'by'), > > 'added' or 'removed' refer to a comparison between current and > > previous XML documents. The 'previous XML document' is 'the last XML > > document that was selected for delivery to that specific=20 > subscription > > before any filter was applied to it' > > [draft-ietf-simple-filter-format-05]. > > Hisham March 6 > You are making a false assumption about the above quoted sentence. > Nothing in that sentence says that the XML document was not sent. > But if you misread it that way, then I guess it needs rephrasing. > > Sean March 7 > I think my point has been missed or I was not clear enough. I am not > making an assumption that the XML document was not sent rather I am > obeying the requirement that the comparison is with the last XML > document "selected for delivery to that specific subscription before > any filter was applied to it." This necessarily implies that the > trigger that determines whether a document is delivered or not is part > of the filter process that determines it MAY not be=20 > sent. Perhaps rephrasing the sentence to say the following will help you=20 understand why I meant with my response. The 'previous XML documen' is "the last XML document that was selected=20 for delivery to that specific subscription before any filter was=20 applied to it and where the XML document was subsequently delivered,=20 after filtering, to the subscriber" What I'm trying to say is that the filters for triggers are used by=20 comparing the current XML document with the XML document that was most=20 recently sent to the subscriber, but before the filters were applied to=20 it. > > Sean March 7 > In particular, in the cases of the examples given previously , > where the trigger uses the child elements 'changed from to' or > 'changed by', if there is a value that occurs in practice in between > the wanted values then the document WILL not be sent precisely because > of the operation of the trigger itself. The trigger occurs within the > scope of filtering i.e. after the comparison of XML Documents according > to the definition in draft-ietf-simple-filter-format-05. > > Sean March 7 > In my example, a trigger is 'Status changed from value A to value C' > but the Status changes in practice from A to B and then again to C.=20 > The > result is that the document would not be delivered when the Status=20 > changes > from A to B nor when the document changes from B to C. The document=20 > that > is 'selected for delivery to that specific subscription before any=20 > filter > was applied to it' (i.e. before the operation of the trigger within the > filter for preferred information) never changes from value A to value=20 > C. > It only changes from A to C when it is the filtered documents rather=20 > than > the unfiltered documents that are compared. Thus if it was desired to=20 > take > this into account, the requirement would have to change to: > "...The 'previous XML document' is 'the last XML document that was=20 > selected > for delivery to that specific subscription AFTER any filter was=20 > applied to it' > > Sean March 6 > > This requirement is self-contradictory. Although it implies that > > attention is given to specific subscriptions during the comparison > > process, it actually (and conversely) supports comparisons of=20 > versions > > on a per presentity rather than on a per subscriber basis.=20 > =A0Subscriber > > specific versions are only created after filtering of the 'raw > > presence document'. The trigger that eventually determines whether a > > document is delivered on a specific subscription is part of the=20 > filter > > process that is excluded from the comparison. > > > > e.g. when a trigger such as 'Status changed from value A to value C' > > is specified but the Status changes in practice from value A to=20 > value > > B and then again to value C. The result is that the document would=20 > not > > be delivered when the Status changes to value C (the document that=20 > was > > previously selected for delivery BEFORE any filter [e.g. current > > trigger] was applied had the Status value B ). The remedy is for the > > watcher to set the trigger appropriate to what is required e.g. > > 'Status changed to value C' rather than =A0'Status changed from value = > A > > to value C'. > > > > Another example is when a trigger such as 'changed by 2' is used and > > the last value of the element / attribute was '6' but the element / > > attribute actually changes to '7' then changes again to '8'. The > > result is that the document would not be delivered when the value > > changes to 8 because it has only changed by 1 with respect to the=20 > last > > (undelivered) version (the document that was previously selected for > > delivery BEFORE any filter [e.g. current trigger] was applied had=20 > the > > element / attribute value 7 ). > > > > The results meet the formal requirement and also minimise the > > scalability issues that would otherwise be associated with keeping > > previous versions of notifications on every subscription that has a > > trigger active. However, they may not meet the expectations of > > watchers that have interpreted the requirement differently i.e. > > stressed "the last XML document that was selected for delivery to=20 > that > > specific subscription" and ignored the fact that "before any filter > > was applied to it" excludes the operation of the trigger itself ! > > > > If the intention (contrary to the stated requirement) is that the > > presence server must retain the last delivered set of information=20 > for > > every subscription involving filters that include triggers, have the > > scalability issues been considered ? > > Hisham March 6 > Why is there a scalability issue? Since you only need to retain a copy > of the last sent XML document to the subscriber *before filtering is > applied*, my guess is that it will be the same for all it was sent to. > You just need to mark it with something that indicates who received=20 > it. > I don't think that will cause scalability issues. > > Sean March 7 > See my previous comment of March 7 (above). In fact, it would be=20 > necessary > to retain a copy of the last sent XML document AFTER filtering for=20 > preferred > information (including triggers) is applied per subscription. I don't understand why you need the xml document AFTER filtering. > This XML > document would differ between subscriptions that invoked different=20 > triggers > and it is simply not good enough to assume it would be the same for=20 > all. > Marking an unfiltered document to indicate who receives it is=20 > inadequate > because the same unfilterred document can result in many different=20 > filtered > documents that are received by different watchers. Yes, but that is the one you need to apply the filter to. I don't=20 understand how you can compare 2 xml documents where one is filtered=20 and the other is not. Hisham > > Regards, > Hisham > > > > > > Note: This problem does not affect =A0the child elements 'added', > > 'removed' or 'changed to', it only affects 'changed from to' and > > 'changed by' or to put it another way it is the inclusion of support > > for =A0'changed from to' and 'changed by' that creates the > > problem. Perhaps, support for these particular > > combinations of child elements should at least be optional > > ?=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > --=_alternative 0035DB728025712B_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hisham Khartabil wrote:

"Perhaps rephrasing the sentenc= e to say the following will help you
understand why I meant with my response.

The 'previous XML documen' is "the last XML document that was selected=
for delivery to that specific subscription before any filter was
applied to it and where the XML document was subsequently delivered,
after filtering, to the subscriber"

What I'm trying to say is that the filters for triggers are used by
comparing the current XML document with the XML document that was most
recently sent to the subscriber, but before the filters were applied to
it."

Sean Leahy> So "the last XML= document that was selected
for delivery to that specific subscription before any filter was
applied to it" could be where the Status changed from 'A' to 'B'
- this did not meet the criterion th= at  it "was subsequently delivered,
after filtering, to the subscriber" (because the trigger is from 'A' t= o 'C').

Sean Leahy> So now we have to loo= k further back for the document that
was the "the next last XML docu= ment that was selected
for delivery to that specific subscription before any filter was
applied to it" - this could be where the Status was marked as 'A'. i.e= . it is
the original document that was sent = to the watcher in that case this doc meets
both the criteria.

Sean Leahy>  However, in the= case that it also was not sent, we have to look
further back again.

Sean Leahy> Each subscription may= have to go back to a different original
unfiltered document.

e.g. Presentity =3D Fred
Document Fred F last sent to Watcher= s A, G,
Document Fred E last sent to Watcher= sB , H
Document Fred D last sent to Watcher= s C, K, R
Document Fred C last sent to Watcher= D, P,
Document Fred B last sent to Watcher= E, M
Document Fred A last sent to Watcher= F

How many versions of Fred's unfilter= ed presence document do we need to keep ?

This depends on the number of subscr= iptions and the triggers operating on each subscription.

Is this the intention ? This seems t= o introduce a scalability problem.

Note: It is the inclusion of support= for =A0'changed from to' and 'changed by' that creates the
<scaleability> problem. Perhap= s, support for these particular combinations of child elements
should at least be optional.

Hisham Khartabil wrote:

Yes, but that [the last sent XML = document to the subscriber before filtering is
applied-my addition] is the one you need to apply the filter to. I don'= t
understand how you can compare 2 xml documents where one is filtered
and the other is not.
Sean Leahy> I never proposed this= . I suggested we either compare 2
filtered documents together or 2 unf= iltered documents together and believed
the original requirement was unclear= which was the case. It appeared to specify on the
one hand that unfiltered documents w= ere compared (thus ignoring the operation of the
trigger in the past in determining w= hat was delivered) and on the other hand that it was
filtered documents that were compare= d (taking account of what was delivered on each
subscription).

Regards,
Sean



Hisham Khartabil <hisham.khart= abil@telio.no>

07/03/2006 16:54

       
        To: &nbs= p;      "Sean Leahy" <Sean.Leahy@marconi.com>= ;
        cc: &nbs= p;      simple@ietf.org
        Subject:=        Re: [Simple] Issue with comparisons for trigger= ring




On Mar 7, 2006, at 10:42 AM, Sean Leahy wrote:

>
> Hisham and others,
>
> Please see in-line comments attached below marked 'Sean March 7':
>
> Regards,
> Sean
>
>
>
> Hisham Khartabil <hisham.khartabil@telio.no>
>
> 06/03/2006 16:20
> =A0 =A0 =A0 =A0
> =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0"Sean Leahy" <Sean.Lea= hy@marconi.com>
> =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0simple@ietf.org
> =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0Re: [Simple] Issue with compar= isons for
> triggerring
>
>
>
>
>  On Mar 6, 2006, at 3:14 PM, Sean Leahy wrote:
>
>  Sean March 6
> > When considering the filtering of preferred information using
>  > 'triggers', the child elements 'changed' ('from', 'to', and= /or
> 'by'),
>  > 'added' or 'removed' refer to a comparison between current = and
>  > previous XML documents. The 'previous XML document' is 'the= last XML
>  > document that was selected for delivery to that specific > subscription
>  > before any filter was applied to it'
>  > [draft-ietf-simple-filter-format-05].
>
>  Hisham March 6
> You are making a false assumption about the above quoted sentence.
>  Nothing in that sentence says that the XML document was not sent= .
> But if you misread it that way, then I guess it needs rephrasing.
>
> Sean March 7
> I think my point has been missed or I was not clear enough. I am not > making an assumption that the XML document was not sent rather I am
> obeying the requirement that the comparison is with the last XML
> document "selected for delivery to that specific subscription bef= ore
> any filter was applied to it." This necessarily implies that the<= br> > trigger that determines whether a document is delivered or not is part=
> of the filter process that <subsequently> determines it MAY not = be
> sent.

Perhaps rephrasing the sentence to say the following will help you
understand why I meant with my response.

The 'previous XML documen' is "the last XML document that was selected=
for delivery to that specific subscription before any filter was
applied to it and where the XML document was subsequently delivered,
after filtering, to the subscriber"

What I'm trying to say is that the filters for triggers are used by
comparing the current XML document with the XML document that was most
recently sent to the subscriber, but before the filters were applied to
it.

>
> Sean March 7
> In particular, in the cases of the examples given previously <below= >,
> where the trigger uses the child elements 'changed from to' or
> 'changed by', if there is a value that occurs in practice in between > the wanted values then the document WILL not be sent precisely because=
> of the operation of the trigger itself. The trigger occurs within the<= br> > scope of filtering i.e. after the comparison of XML Documents accordin= g
> to the definition in draft-ietf-simple-filter-format-05.
>
> Sean March 7
> In my example, a trigger is 'Status changed from value A to value C' >  but the Status changes in practice from A to B and then again to= C.
> The
> result is that the document would not be delivered when the Status
> changes
> from A to B nor when the document changes from B to C. The document > that
> is 'selected for delivery to that specific subscription before any
> filter
> was applied to it' (i.e. before the operation of the trigger within th= e
> filter for preferred information) never changes from value A to value =
> C.
> It only changes from A to C wh= en it is the filtered documents rather
> than
> the unfiltered documents that are compared. Thus if it was desired to =
> take
> this into account, the requirement would have to change to:
> "...The 'previous XML document' is 'the last XML document that wa= s
> selected
> for delivery to that specific subscription AFTER any filter was
> applied to it'
>
> Sean March 6
>  > This requirement is self-contradictory. Although it implies= that
>  > attention is given to specific subscriptions during the com= parison
>  > process, it actually (and conversely) supports comparisons = of
> versions
>  > on a per presentity rather than on a per subscriber basis. =
> =A0Subscriber
>  > specific versions are only created after filtering of the '= raw
>  > presence document'. The trigger that eventually determines = whether a
>  > document is delivered on a specific subscription is part of= the
> filter
>  > process that is excluded from the comparison.
>  >
>  > e.g. when a trigger such as 'Status changed from value A to= value C'
>  > is specified but the Status changes in practice from value = A to
> value
>  > B and then again to value C. The result is that the documen= t would
> not
>  > be delivered when the Status changes to value C (the docume= nt that
> was
>  > previously selected for delivery BEFORE any filter [e.g. cu= rrent
>  > trigger] was applied had the Status value B ). The remedy i= s for the
>  > watcher to set the trigger appropriate to what is required = e.g.
>  > 'Status changed to value C' rather than =A0'Status changed = from value
> A
>  > to value C'.
>  >
>  > Another example is when a trigger such as 'changed by 2' is= used and
>  > the last value of the element / attribute was '6' but the e= lement /
>  > attribute actually changes to '7' then changes again to '8'= . The
>  > result is that the document would not be delivered when the= value
>  > changes to 8 because it has only changed by 1 with respect = to the
> last
>  > (undelivered) version (the document that was previously sel= ected for
>  > delivery BEFORE any filter [e.g. current trigger] was appli= ed had
> the
>  > element / attribute value 7 ).
>  >
>  > The results meet the formal requirement and also minimise t= he
>  > scalability issues that would otherwise be associated with = keeping
>  > previous versions of notifications on every subscription th= at has a
>  > trigger active. However, they may not meet the expectations= of
>  > watchers that have interpreted the requirement differently = i.e.
>  > stressed "the last XML document that was selected for = delivery to
> that
>  > specific subscription" and ignored the fact that "= ;before any filter
>  > was applied to it" excludes the operation of the trigg= er itself !
>  >
>  > If the intention (contrary to the stated requirement) is th= at the
>  > presence server must retain the last delivered set of infor= mation
> for
>  > every subscription involving filters that include triggers,= have the
>  > scalability issues been considered ?
>
>  Hisham March 6
> Why is there a scalability issue? Since you only need to retain a copy=
>  of the last sent XML document to the subscriber *before filterin= g is
>  applied*, my guess is that it will be the same for all it was se= nt to.
>  You just need to mark it with something that indicates who recei= ved
> it.
>  I don't think that will cause scalability issues.
>
> Sean March 7
> See my previous comment of March 7 (above). In fact, it would be
> necessary
> to retain a copy of the last sent XML document AFTER filtering for
> preferred
> information (including triggers) is applied per subscription.

I don't understand why you need the xml document AFTER filtering.


>  This XML
> document would differ between subscriptions that invoked different
> triggers
> and it is simply not good enough to assume it would be the same for > all.
> Marking an unfiltered document to indicate who receives it is
> inadequate
> because the same unfilterred document can result in many different
> filtered
> documents that are received by different watchers.

Yes, but that is the one you need to apply the filter to. I don't
understand how you can compare 2 xml documents where one is filtered
and the other is not.

Hisham

>
>  Regards,
>  Hisham
>
>
>  >
>  > Note: This problem does not affect =A0the child elements 'a= dded',
>  > 'removed' or 'changed to', it only affects 'changed from to= ' and
>  > 'changed by' or to put it another way it is the inclusion o= f support
>  > for =A0'changed from to' and 'changed by' that creates the<= /font>
>  > <scaleability>= ; problem. Perhaps, support for these particular
>  > combinations of child elements should at least be optional<= br> >  > ?=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F
>  > Simple mailing list
> > Simple@ietf.org
>  > https://www1.ietf.org/mailman/listinfo/simple
>
>
>

--=_alternative 0035DB728025712B_=-- --===============0239799436== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0239799436==-- From simple-bounces@ietf.org Wed Mar 08 07:43:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGy0m-000181-1i; Wed, 08 Mar 2006 07:43:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGy0k-00016k-Fg for simple@ietf.org; Wed, 08 Mar 2006 07:43:26 -0500 Received: from smtp16.clb.oleane.net ([213.56.31.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGy0j-0007zG-Sg for simple@ietf.org; Wed, 08 Mar 2006 07:43:26 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp16.clb.oleane.net with ESMTP id k28ChFgj015820 for ; Wed, 8 Mar 2006 13:43:24 +0100 Message-Id: <200603081243.k28ChFgj015820@smtp16.clb.oleane.net> From: "Chantal Ladouce" To: Date: Wed, 8 Mar 2006 13:42:45 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZCrcwspsnjji5GTIieXzYxaVgjcg== X-Spam-Score: 0.4 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Subject: [Simple] IMS or UMA? How to Achieve FMC? 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="===============2123356834==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============2123356834== Content-Type: multipart/related; boundary="----=_NextPart_000_0133_01C642B6.2E4BD2C0" This is a multi-part message in MIME format. ------=_NextPart_000_0133_01C642B6.2E4BD2C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0134_01C642B6.2E4E43C0" ------=_NextPart_001_0134_01C642B6.2E4E43C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IMS or UMA? How to Achieve FMC? At the 2006 Wireless/WiFi Convergence Conference to be held in Paris on May 16 to May 19, distinguished experts and key players in the convergence field will address technical issues. Moreover, carriers like BT, Orange, Vonage (etc) will discuss their commercial experience and technological choices. Get all details at: http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006intro.htm ------=_NextPart_001_0134_01C642B6.2E4E43C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IMS or UMA?

How to Achieve FMC?

 

At the 2006 Wireless/WiFi Convergence Conference to be held in Paris on May 16 to May = 19,

distinguished experts and key players in the convergence field will address technical issues. =

Moreover, carriers like BT, Orange, Vonage (etc) will discuss = their commercial experience and

    &nb= sp;  technological choices.

 

    &nb= sp; Get all details at:

    &nb= sp; http://www.upperside.fr/wirelessconvergence2006/wwconvergence= 2006intro.htm

 

 

------=_NextPart_001_0134_01C642B6.2E4E43C0-- ------=_NextPart_000_0133_01C642B6.2E4BD2C0 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAArAJUDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDzYFiT 1pPJmbpmvdvDfhrw9rnha2vRpdv5s0OGZR0fGD+teUXKxWV3PbSKN8MhTH0OKR9RhFTxMpQk7cpz 7WkjDqadHpsrHoa+gNB8GaQNCszd6fE87RhnZhzk815Z4uiXQPEt3YrGERW3xjH8J6UWJw8sJVqu Ddrfic5Ho7nrXs/wjt/s3hmeLv8AaCf0FQfDzw9Yan4YTUNQtEledyULDoo4FYera1Z2fli0vbvT bf8AtVoEWyAw+NoO7PbOaaObH1sNKEqdGL06nsApa4jWPidpuia7caLJY31xdQoCogj3+YcZ4xTb X4q6HN4autbkiuIRayiKS3ZcuXPQD8qDwjuaK89PxatbcQTahod/Z2s7AJO+1hz7A1VfXL8/GiGy S/lOntZ+b5Ib5Mbc5xQB6ZRXnw+LFtcSXB03Q7+9gt2KvOm0DjqcGrM/xU0KHwtHr+y4aOSYwCHb 84cDJB/CgDuKQjNcCnxSUPD9p8OalBHMQFcBX6+wNW9e+JFjo2uLo0On3V7eMgcxxYXAIz39qAOx JA61k3XibRLKcxXWpW8TrwVLdKx9H8eR63ey6c+kX1jOsZcGVQU4H94dKy/h/o2m6nZ311e2kdxK 1yw3OM8ZpnXQo05U5VKl7Lt5nb2epWN/CZrO6jmjXqUbgVRk8WaBFKYn1W3D5xjdXEWqjTNS8WWt oPLiS3LIqnAHNQ6Je6Jb+HUin0Ce8co3nTpDnBOehpHasvhq9WtNrX1Vz1K3uIrqES28iyxt0ZTk GisHwOmnR+H1/sqeWWBnJ/fH5kPpRQeXWgqdRwXTuct8F9U8/Sb3THYlraXegPo3/wBeuc8SeHHn +L8enxgiK9mSc+m3qf1Bql8KtU/s7xrDCxxHeoYiP9rqK9mm0KGbxTb64xHmwW7QhcepzmkddWTp VW+6IdZ8RW+iatpGnOo/4mEpiH+yAOP1wK86+N+kMLzTtUiU5mzbvjueorH+KevPN48j8h+NL2hc H+MHcf6V6vfafbeNPDenSlhsLxXKn6EEigwSdPll3GxBfCnw+UkBTZWOT/vbf8a8esdPl1nw1pTC 7tYZBqzyMJ5QhfO3OM9a9D+MmqfYvCcVijYe9mC4H90cmvNtOv47HRNDSTT7a783UmAM65Kcp0oG o/unLuzukNlpvxhvdbvNW0+G2EHlYaYb1bA4xUvjW28M+KdBk03QdW0yG/nuFlCrIB5z+hx3rz7W n0yL4raw2raXPqVv5rfuLc4bOBg1v+HpvBlz4hsYLfwXqdtM8y7JpHO2Ns8E0zmIrfwve62iabY6 DpQuLVwtzMb9pduOCSmeO9dgfBmqf8LKh1fy4xp6WX2curcg7NvSsTwp4hNnd+Lbq20yzgntpAoa NcbyXIBb19a7aK613TWjvdSvbe5sPKL3DCPYY+M8etBtCg5R5rnntp8Odc0Z7u3/AOEdttXWSQtF cG9aLAPqoNah8Aa0ngJtNGm6W93Jdmdrfc21Vxxhs/ersl8a2Cwyyz29zDsjEqq6cuhOAR+YqRPF 9i0yxSQ3ELmRIysiYI3fdP0oH9Wqv7J5fdfDvxLdJDHZaEmlSK4JuF1Fn4+lb/i7wXrV9rFreLpF nqiR26Ru4nMMrMBgkt35zXXTeNNOjkeKOKeZ0dlIVeoX7zD2FLJ4005WXZFcSo0aymRIyQqt0J9K AeHrWvynEeFfA3iKy8YxanJajS9ORCJLcXhmEmQR/UflWrpEfiXwk13ZwaN9sgkmMiOHA4JroofG enSzRp5c6pKzLHMU+R9oySD+FNj8b6Y0buY51RYmlQlf9Yo6kUHTRjWpqUXTunuY2i+HNVu11y91 K3W2m1KLYke7JWotNufE+i6GNG/4R8zbFZBKsgwQc8/rXQp4y0/yZ3mjuIWhRZBG6fM6t0wKV/GF nHb7pba5imMvlrA8eGY4zxmg3davJtSp3u1p8tLa9iPwPo1zoehGG+2rNLIZCoP3c9qK1dK1W21m 0+0Wu4hWKOrDBVh1BooPNrSnOo5T0bPmWyvJNP1KC8i+/BKJBj2PSvU/+F4wEcaFMTj/AJ6jrXlA UGXGOOtTW6KzYIyKR7Tw0az94h1Ce41LULm9lX57iRpG/E9K7/wj8UH8PeH4NKudNkumgJCSLIB8 ueB+FcWQBkUwDjNBs8DTaSZ0njXxOfGl9bT/AGdraK3QqELbsknOa2PC/gZvE+hWE0N8tt/Z980u Cmd/3Tj26VxkYww+lexfCb/kWZ/+vg/yFNE4/D06OF91dSXS/h/Jp3xAvPFDX6SLc7v3GzkZx3/C u02DsB+VHrSj7pPeg+cOE0T4b/2bJrv2jUfOj1Y5ARMGM7sg+5rRbwjdXhVNS1iW4ijjMcaIgXqM ZPr0rqe496XqKDWFecFZM5M+C5biOQXmpNLJ5KwRsIwAiggj8eKs33hJL2W8kN0yPcxRopA5Qp0I roxzQKC/rVXucm3ghUgtPIvAJoI2jZ5Yg4k3HJbB75rR07w8unX0l155m32ywFSoHTPPHrmtvotN kOEOKBSxVWSs2eeWmi30t/aWJguo7O3nkJWRAFjUg9GHXrWvH4IItZbVr1fK8po49sKqwB7k9663 Az0oA5+lM1njaj20ObvfCEd7I8hu3Qm3jhQqv3SpyDTLrwlc3sayXmpma6SUSIzRjYvGMba6juKM dBQZLE1O5n6Nph0qxMDzeczOXLBAoyewA7UVoUUjGUuZ3e5//9k= ------=_NextPart_000_0133_01C642B6.2E4BD2C0-- --===============2123356834== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============2123356834==-- From simple-bounces@ietf.org Wed Mar 08 08:31:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGylZ-0006ZG-AK; Wed, 08 Mar 2006 08:31:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGylY-0006Wt-Oc for simple@ietf.org; Wed, 08 Mar 2006 08:31:48 -0500 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGylV-00010Y-D2 for simple@ietf.org; Wed, 08 Mar 2006 08:31:48 -0500 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 Date: Wed, 8 Mar 2006 14:29:34 +0100 Message-ID: <31721CD4D0090B4BA32CBA5E2C40AE9001E34721@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Filtering: possible security issue? Thread-Index: AcZCtFaMXJWwLrkeTFC+ish4irgcOA== From: To: X-OriginalArrivalTime: 08 Mar 2006 13:29:41.0212 (UTC) FILETIME=[5AD569C0:01C642B4] X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Simple] Filtering: possible security issue? 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: , Errors-To: simple-bounces@ietf.org Hi, draft-ietf-simple-event-filter-funct-05.txt says: "If polite blocking is used by the notifier, the notifier may choose to ignore the filter, by choosing to deliver notifications containing bogus information in the unauthorised elements or attributes." I think it can result in a security leak since the subscriber could create such filter, that if ignored, gives the subscriber information that he/she is polite blocked... Could anyone please post any suggestions/comments? Best regards, Michal Burda _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 08 08:53:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGz66-0002h1-9U; Wed, 08 Mar 2006 08:53:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGz64-0002gq-Rh for simple@ietf.org; Wed, 08 Mar 2006 08:53:00 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGz64-0001nJ-DC for simple@ietf.org; Wed, 08 Mar 2006 08:53:00 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k28Dpw42008132; Wed, 8 Mar 2006 15:51:59 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 15:52:59 +0200 Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 8 Mar 2006 15:52:56 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k28Dqu702792; Wed, 8 Mar 2006 15:52:56 +0200 (EET) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by kusti.research.nokia.com (Postfix) with ESMTP id A3D5793B75; Wed, 8 Mar 2006 15:52:56 +0200 (EET) Subject: Re: [Simple] Issue with comparisons for triggerring From: Jari Urpalainen To: ext Sean Leahy In-Reply-To: References: Content-Type: text/plain Date: Wed, 08 Mar 2006 15:52:56 +0200 Message-Id: <1141825976.16486.29.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2006 13:52:56.0410 (UTC) FILETIME=[9A6FBBA0:01C642B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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: , Errors-To: simple-bounces@ietf.org On Wed, 2006-03-08 at 09:48 +0000, ext Sean Leahy wrote: > > Hisham Khartabil wrote: > > "Perhaps rephrasing the sentence to say the following will help you > understand why I meant with my response. > > The 'previous XML documen' is "the last XML document that was > selected > for delivery to that specific subscription before any filter was > applied to it and where the XML document was subsequently delivered, > after filtering, to the subscriber" > > What I'm trying to say is that the filters for triggers are used by > comparing the current XML document with the XML document that was > most > recently sent to the subscriber, but before the filters were applied > to > it." > > Sean Leahy> So "the last XML document that was selected > for delivery to that specific subscription before any filter was > applied to it" could be where the Status changed from 'A' to 'B' > - this did not meet the criterion that it "was subsequently > delivered, > after filtering, to the subscriber" (because the trigger is from 'A' > to 'C'). > > Sean Leahy> So now we have to look further back for the document > that > was the "the next last XML document that was selected > for delivery to that specific subscription before any filter was > applied to it" - this could be where the Status was marked as 'A'. > i.e. it is > the original document that was sent to the watcher in that case this > doc meets > both the criteria. > > Sean Leahy> However, in the case that it also was not sent, we have > to look > further back again. > > Sean Leahy> Each subscription may have to go back to a different > original > unfiltered document. > > e.g. Presentity = Fred > Document Fred F last sent to Watchers A, G, > Document Fred E last sent to WatchersB , H > Document Fred D last sent to Watchers C, K, R > Document Fred C last sent to Watcher D, P, > Document Fred B last sent to Watcher E, M > Document Fred A last sent to Watcher F > > How many versions of Fred's unfiltered presence document do we need to > keep ? > Looks like you are proposing 6 ;-). If I were to implement this (which is btw. quite challenging), I would probably maintain only one document, and the "trigger state" per watcher could be kept e.g. within the watchers filter rule document, i.e. it could be e.g. an additional attribute value within the element. But this is of course an implementation issue. So imo keeping this "state information" does not mean that you have to maintain the full published information. Definitely this is additional state information to remember but I doubt that it is not a major issue considering all the other tasks that you have to implement. Another story is whether the text needs clarification or not. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 08 08:54:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGz7e-0003qi-St; Wed, 08 Mar 2006 08:54:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGz7d-0003iW-Ga for simple@ietf.org; Wed, 08 Mar 2006 08:54:37 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGz7b-0001ri-Ry for simple@ietf.org; Wed, 08 Mar 2006 08:54:37 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 6A0E919447B for ; Wed, 8 Mar 2006 14:54:34 +0100 (CET) Received: from [192.168.1.72] ([192.168.1.72]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 14:53:00 +0100 In-Reply-To: <31721CD4D0090B4BA32CBA5E2C40AE9001E34721@carrera.eu.tieto.com> References: <31721CD4D0090B4BA32CBA5E2C40AE9001E34721@carrera.eu.tieto.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <85720cbf0d245e0ff3c4da85be477bc7@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Filtering: possible security issue? Date: Wed, 8 Mar 2006 14:55:00 +0100 To: X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 08 Mar 2006 13:53:00.0528 (UTC) FILETIME=[9CE41700:01C642B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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: , Errors-To: simple-bounces@ietf.org Ignoring the filter in this sense does not mean not applying it. it means that you replace the information that the filter is asking for in a element with bogus information. For elements, this doesnt apply i dont think. Hisham On Mar 8, 2006, at 2:29 PM, wrote: > Hi, > > draft-ietf-simple-event-filter-funct-05.txt says: "If polite blocking > is > used by the notifier, the notifier may choose to ignore the filter, by > choosing to deliver notifications containing bogus information in the > unauthorised elements or attributes." > > I think it can result in a security leak since the subscriber could > create such filter, that if ignored, gives the subscriber information > that he/she is polite blocked... > > Could anyone please post any suggestions/comments? > > > Best regards, > > > Michal Burda > > > _______________________________________________ > 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 Mar 08 09:06:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGzIl-00084j-HB; Wed, 08 Mar 2006 09:06:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGzIk-00084e-KU for simple@ietf.org; Wed, 08 Mar 2006 09:06:06 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGzIj-0002MU-O7 for simple@ietf.org; Wed, 08 Mar 2006 09:06:06 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 8A573194468 for ; Wed, 8 Mar 2006 15:06:04 +0100 (CET) Received: from [192.168.1.72] ([192.168.1.72]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 15:04:30 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <3994086d672217e7a8f00620cf6f3431@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Simple] Issue with comparisons for triggerring Date: Wed, 8 Mar 2006 15:06:30 +0100 To: "Sean Leahy" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 08 Mar 2006 14:04:30.0471 (UTC) FILETIME=[38210970:01C642B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 354d6627469d0be959806e15912c47f1 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: , Errors-To: simple-bounces@ietf.org On Mar 8, 2006, at 10:48 AM, Sean Leahy wrote: > > Hisham Khartabil wrote: > > "Perhaps rephrasing the sentence to say the following will help you > understand why I meant with my response. > > The 'previous XML documen' is "the last XML document that was = selected > for delivery to that specific subscription before any filter was > applied to it and where the XML document was subsequently delivered, > after filtering, to the subscriber" > > What I'm trying to say is that the filters for triggers are used by > comparing the current XML document with the XML document that was = most > recently sent to the subscriber, but before the filters were applied=20= > to > it." > > Sean Leahy> So "the last XML document that was selected > for delivery to that specific subscription before any filter was > applied to it" could be where the Status changed from 'A' to 'B' > - this did not meet the criterion that =A0it "was subsequently = delivered, > after filtering, to the subscriber" (because the trigger is from 'A'=20= > to 'C'). > > Sean Leahy> So now we have to look further back for the document that > was the "the next last XML document that was selected > for delivery to that specific subscription before any filter was > applied to it" - this could be where the Status was marked as 'A'.=20 > i.e. it is > the original document that was sent to the watcher in that case this=20= > doc meets > both the criteria. > > Sean Leahy> =A0However, in the case that it also was not sent, we have=20= > to look > further back again. > > Sean Leahy> Each subscription may have to go back to a different=20 > original > unfiltered document. > > e.g. Presentity =3D Fred > Document Fred F last sent to Watchers A, G, > Document Fred E last sent to WatchersB , H > Document Fred D last sent to Watchers C, K, R > Document Fred C last sent to Watcher D, P, > Document Fred B last sent to Watcher E, M > Document Fred A last sent to Watcher F > > How many versions of Fred's unfiltered presence document do we need to=20= > keep ? As many as needed where all Fred's active subscribers have been marked=20= next to one xml document. > > This depends on the number of subscriptions and the triggers operating=20= > on each subscription. Correct > > Is this the intention ? This seems to introduce a scalability problem. Granted you have to keep copies of a few XML documents, but I doubt it=20= will introduce scalability problems. There is only one way to prove me=20= wrong however :) Hisham > > Note: It is the inclusion of support for =A0'changed from to' and=20 > 'changed by' that creates the > problem. Perhaps, support for these particular=20 > combinations of child elements > should at least be optional. > > Hisham Khartabil wrote: > > Yes, but that [the last sent XML document to the subscriber before=20 > filtering is > applied-my addition] is the one you need to apply the filter to. I=20 > don't > understand how you can compare 2 xml documents where one is filtered > and the other is not. > > Sean Leahy> I never proposed this. I suggested we either compare 2 > filtered documents together or 2 unfiltered documents together and=20 > believed > the original requirement was unclear which was the case. It appeared=20= > to specify on the > one hand that unfiltered documents were compared (thus ignoring the=20 > operation of the > trigger in the past in determining what was delivered) and on the=20 > other hand that it was > filtered documents that were compared (taking account of what was=20 > delivered on each > subscription). > > Regards, > Sean > > > > Hisham Khartabil > > 07/03/2006 16:54 > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0"Sean Leahy" = > =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0simple@ietf.org > =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0Re: [Simple] Issue with = comparisons for=20 > triggerring > > > > > On Mar 7, 2006, at 10:42 AM, Sean Leahy wrote: > > > > > Hisham and others, > > > > Please see in-line comments attached below marked 'Sean March 7': > > > > Regards, > > Sean > > > > > > > > Hisham Khartabil > > > > 06/03/2006 16:20 > > =A0 =A0 =A0 =A0 > > =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0"Sean Leahy" = > > =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0simple@ietf.org > > =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0Re: [Simple] Issue with = comparisons for > > triggerring > > > > > > > > > > =A0On Mar 6, 2006, at 3:14 PM, Sean Leahy wrote: > > > > =A0Sean March 6 > > > When considering the filtering of preferred information using > > =A0> 'triggers', the child elements 'changed' ('from', 'to', and/or > > 'by'), > > =A0> 'added' or 'removed' refer to a comparison between current and > > =A0> previous XML documents. The 'previous XML document' is 'the = last=20 > XML > > =A0> document that was selected for delivery to that specific > > subscription > > =A0> before any filter was applied to it' > > =A0> [draft-ietf-simple-filter-format-05]. > > > > =A0Hisham March 6 > > You are making a false assumption about the above quoted sentence. > > =A0Nothing in that sentence says that the XML document was not = sent. > > But if you misread it that way, then I guess it needs rephrasing. > > > > Sean March 7 > > I think my point has been missed or I was not clear enough. I am = not > > making an assumption that the XML document was not sent rather I am > > obeying the requirement that the comparison is with the last XML > > document "selected for delivery to that specific subscription = before > > any filter was applied to it." This necessarily implies that the > > trigger that determines whether a document is delivered or not is=20= > part > > of the filter process that determines it MAY not be > > sent. > > Perhaps rephrasing the sentence to say the following will help you > understand why I meant with my response. > > The 'previous XML documen' is "the last XML document that was = selected > for delivery to that specific subscription before any filter was > applied to it and where the XML document was subsequently delivered, > after filtering, to the subscriber" > > What I'm trying to say is that the filters for triggers are used by > comparing the current XML document with the XML document that was = most > recently sent to the subscriber, but before the filters were applied=20= > to > it. > > > > > Sean March 7 > > In particular, in the cases of the examples given previously=20 > , > > where the trigger uses the child elements 'changed from to' or > > 'changed by', if there is a value that occurs in practice in = between > > the wanted values then the document WILL not be sent precisely=20 > because > > of the operation of the trigger itself. The trigger occurs within=20= > the > > scope of filtering i.e. after the comparison of XML Documents=20 > according > > to the definition in draft-ietf-simple-filter-format-05. > > > > Sean March 7 > > In my example, a trigger is 'Status changed from value A to value = C' > > =A0but the Status changes in practice from A to B and then again to = C. > > The > > result is that the document would not be delivered when the Status > > changes > > from A to B nor when the document changes from B to C. The document > > that > > is 'selected for delivery to that specific subscription before any > > filter > > was applied to it' (i.e. before the operation of the trigger within=20= > the > > filter for preferred information) never changes from value A to=20 > value > > C. > > It only changes from A to C when it is the filtered documents rather > > than > > the unfiltered documents that are compared. Thus if it was desired=20= > to > > take > > this into account, the requirement would have to change to: > > "...The 'previous XML document' is 'the last XML document that was > > selected > > for delivery to that specific subscription AFTER any filter was > > applied to it' > > > > Sean March 6 > > =A0> This requirement is self-contradictory. Although it implies = that > > =A0> attention is given to specific subscriptions during the=20 > comparison > > =A0> process, it actually (and conversely) supports comparisons of > > versions > > =A0> on a per presentity rather than on a per subscriber basis. > > =A0Subscriber > > =A0> specific versions are only created after filtering of the 'raw > > =A0> presence document'. The trigger that eventually determines=20 > whether a > > =A0> document is delivered on a specific subscription is part of = the > > filter > > =A0> process that is excluded from the comparison. > > =A0> > > =A0> e.g. when a trigger such as 'Status changed from value A to=20 > value C' > > =A0> is specified but the Status changes in practice from value A = to > > value > > =A0> B and then again to value C. The result is that the document=20= > would > > not > > =A0> be delivered when the Status changes to value C (the document=20= > that > > was > > =A0> previously selected for delivery BEFORE any filter [e.g. = current > > =A0> trigger] was applied had the Status value B ). The remedy is = for=20 > the > > =A0> watcher to set the trigger appropriate to what is required = e.g. > > =A0> 'Status changed to value C' rather than =A0'Status changed = from=20 > value > > A > > =A0> to value C'. > > =A0> > > =A0> Another example is when a trigger such as 'changed by 2' is = used=20 > and > > =A0> the last value of the element / attribute was '6' but the=20 > element / > > =A0> attribute actually changes to '7' then changes again to '8'. = The > > =A0> result is that the document would not be delivered when the = value > > =A0> changes to 8 because it has only changed by 1 with respect to = the > > last > > =A0> (undelivered) version (the document that was previously = selected=20 > for > > =A0> delivery BEFORE any filter [e.g. current trigger] was applied = had > > the > > =A0> element / attribute value 7 ). > > =A0> > > =A0> The results meet the formal requirement and also minimise the > > =A0> scalability issues that would otherwise be associated with=20 > keeping > > =A0> previous versions of notifications on every subscription that=20= > has a > > =A0> trigger active. However, they may not meet the expectations of > > =A0> watchers that have interpreted the requirement differently = i.e. > > =A0> stressed "the last XML document that was selected for delivery = to > > that > > =A0> specific subscription" and ignored the fact that "before any=20= > filter > > =A0> was applied to it" excludes the operation of the trigger = itself ! > > =A0> > > =A0> If the intention (contrary to the stated requirement) is that = the > > =A0> presence server must retain the last delivered set of = information > > for > > =A0> every subscription involving filters that include triggers, = have=20 > the > > =A0> scalability issues been considered ? > > > > =A0Hisham March 6 > > Why is there a scalability issue? Since you only need to retain a=20= > copy > > =A0of the last sent XML document to the subscriber *before = filtering=20 > is > > =A0applied*, my guess is that it will be the same for all it was = sent=20 > to. > > =A0You just need to mark it with something that indicates who = received > > it. > > =A0I don't think that will cause scalability issues. > > > > Sean March 7 > > See my previous comment of March 7 (above). In fact, it would be > > necessary > > to retain a copy of the last sent XML document AFTER filtering for > > preferred > > information (including triggers) is applied per subscription. > > I don't understand why you need the xml document AFTER filtering. > > > > =A0This XML > > document would differ between subscriptions that invoked different > > triggers > > and it is simply not good enough to assume it would be the same for > > all. > > Marking an unfiltered document to indicate who receives it is > > inadequate > > because the same unfilterred document can result in many different > > filtered > > documents that are received by different watchers. > > Yes, but that is the one you need to apply the filter to. I don't > understand how you can compare 2 xml documents where one is filtered > and the other is not. > > Hisham > > > > > =A0Regards, > > =A0Hisham > > > > > > =A0> > > =A0> Note: This problem does not affect =A0the child elements = 'added', > > =A0> 'removed' or 'changed to', it only affects 'changed from to' = and > > =A0> 'changed by' or to put it another way it is the inclusion of=20= > support > > =A0> for =A0'changed from to' and 'changed by' that creates the > > =A0> problem. Perhaps, support for these particular > > =A0> combinations of child elements should at least be optional > > =A0> ?_______________________________________________ > > =A0> Simple mailing list > > > Simple@ietf.org > > =A0> 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 Mar 08 10:45:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH0qU-0007wr-6j; Wed, 08 Mar 2006 10:45:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH0qS-0007vY-3Q for simple@ietf.org; Wed, 08 Mar 2006 10:45:00 -0500 Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH0qR-0005uu-Dk for simple@ietf.org; Wed, 08 Mar 2006 10:45:00 -0500 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id k28EMVHd002475; Wed, 8 Mar 2006 15:44:48 GMT (envelope-from Sean.Leahy@marconi.com) To: "Jari Urpalainen , "Hisham Khartabil Subject: Re: [Simple] Issue with comparisons for triggerring MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Sean Leahy" Date: Wed, 8 Mar 2006 15:22:06 +0000 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 08/03/2006 15:44:12, Serialize complete at 08/03/2006 15:44:12 X-Spam-Score: 0.5 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 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: , Content-Type: multipart/mixed; boundary="===============0552787875==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============0552787875== Content-Type: multipart/alternative; boundary="=_alternative 00546BF28025712B_=" This is a multipart message in MIME format. --=_alternative 00546BF28025712B_= Content-Type: text/plain; charset="us-ascii" Jari and Hisham, I woud suggest changing the requirement to: "....... Previous XML document in this context refers to the last XML document that was delivered to that specific subscription." As Jari said, the rest is then an implementation issue. I think for example, Jari's solution works and the only overhead is the extra field 'last sent value' (per trigger) in the watcher's filter rule document (the latter doc has to be kept in any case). This field would be updated every time a doc was sent to the watcher. I think I was confused before believing that you need to remember all the info from the 'previous XML Document' - you only need to keep the value of the last sent value for each trigger. I blame the original requirement for confusing me. Why do we need the struck-through text - it only seems to confuse. "The element is used to identify the XML element or attribute, from the package specific XML document, whose value MUST change, compared to the "previous XML document", in order to activate the trigger and cause the content to be delivered. Previous XML document in this context refers to the last XML document that was selected for delivery delivered to that specific subscription before any filter was applied to it." Regards, Sean Jari Urpalainen 08/03/2006 13:52 To: ext Sean Leahy cc: "Hisham Khartabil > Hisham Khartabil wrote: > > "Perhaps rephrasing the sentence to say the following will help you > understand why I meant with my response. > > The 'previous XML documen' is "the last XML document that was > selected > for delivery to that specific subscription before any filter was > applied to it and where the XML document was subsequently delivered, > after filtering, to the subscriber" > > What I'm trying to say is that the filters for triggers are used by > comparing the current XML document with the XML document that was > most > recently sent to the subscriber, but before the filters were applied > to > it." > > Sean Leahy> So "the last XML document that was selected > for delivery to that specific subscription before any filter was > applied to it" could be where the Status changed from 'A' to 'B' > - this did not meet the criterion that it "was subsequently > delivered, > after filtering, to the subscriber" (because the trigger is from 'A' > to 'C'). > > Sean Leahy> So now we have to look further back for the document > that > was the "the next last XML document that was selected > for delivery to that specific subscription before any filter was > applied to it" - this could be where the Status was marked as 'A'. > i.e. it is > the original document that was sent to the watcher in that case this > doc meets > both the criteria. > > Sean Leahy> However, in the case that it also was not sent, we have > to look > further back again. > > Sean Leahy> Each subscription may have to go back to a different > original > unfiltered document. > > e.g. Presentity = Fred > Document Fred F last sent to Watchers A, G, > Document Fred E last sent to WatchersB , H > Document Fred D last sent to Watchers C, K, R > Document Fred C last sent to Watcher D, P, > Document Fred B last sent to Watcher E, M > Document Fred A last sent to Watcher F > > How many versions of Fred's unfiltered presence document do we need to > keep ? > Looks like you are proposing 6 ;-). If I were to implement this (which is btw. quite challenging), I would probably maintain only one document, and the "trigger state" per watcher could be kept e.g. within the watchers filter rule document, i.e. it could be e.g. an additional attribute value within the element. But this is of course an implementation issue. So imo keeping this "state information" does not mean that you have to maintain the full published information. Definitely this is additional state information to remember but I doubt that it is not a major issue considering all the other tasks that you have to implement. Another story is whether the text needs clarification or not. br, Jari --=_alternative 00546BF28025712B_= Content-Type: text/html; charset="us-ascii"
Jari and Hisham,

I woud suggest changing the requirement to:

".......  Previous XML document in this context refers to the last XML document that was delivered to that specific subscription." As Jari said, the rest is then an implementation issue.

I think for example, Jari's solution works and the only overhead is the extra field 'last sent value' (per trigger) in the watcher's filter rule document (the latter doc has to be kept in any case). This field <or an equivalent> would be updated every time a doc was sent to the watcher. I think I was confused before believing that you need to remember all the info from the 'previous XML Document' - you only need to keep the value of the last sent value for each trigger. I blame the original requirement for confusing me. Why do we need the struck-through text - it only seems to confuse.

"The <changed> element is used to identify the XML element or attribute, from the package specific XML document, whose value MUST change, compared to the "previous XML document", in order to activate the trigger and cause the content to be delivered.  Previous XML document in this context refers to the last XML document that was selected for delivery delivered to that specific subscription before any filter was applied to it."

Regards,
Sean



Jari Urpalainen <jari.urpalainen@nokia.com>

08/03/2006 13:52

       
        To:        ext Sean Leahy <Sean.Leahy@marconi.com>
        cc:        "Hisham Khartabil <hisham.khartabil", simple@ietf.org
        Subject:        Re: [Simple] Issue with comparisons for triggerring



On Wed, 2006-03-08 at 09:48 +0000, ext Sean Leahy wrote:
>
> Hisham Khartabil wrote:
>
> "Perhaps rephrasing the sentence to say the following will help you
> understand why I meant with my response.
>
> The 'previous XML documen' is "the last XML document that was
> selected
> for delivery to that specific subscription before any filter was
> applied to it and where the XML document was subsequently delivered,
> after filtering, to the subscriber"
>
> What I'm trying to say is that the filters for triggers are used by
> comparing the current XML document with the XML document that was
> most
> recently sent to the subscriber, but before the filters were applied
> to
> it."
>
> Sean Leahy> So "the last XML document that was selected
> for delivery to that specific subscription before any filter was
> applied to it" could be where the Status changed from 'A' to 'B'
> - this did not meet the criterion that  it "was subsequently
> delivered,
> after filtering, to the subscriber" (because the trigger is from 'A'
> to 'C').
>
> Sean Leahy> So now we have to look further back for the document
> that  
> was the "the next last XML document that was selected
> for delivery to that specific subscription before any filter was
> applied to it" - this could be where the Status was marked as 'A'.
> i.e. it is
> the original document that was sent to the watcher in that case this
> doc meets
> both the criteria.
>
> Sean Leahy>  However, in the case that it also was not sent, we have
> to look
> further back again.
>
> Sean Leahy> Each subscription may have to go back to a different
> original  
> unfiltered document.
>
> e.g. Presentity = Fred
> Document Fred F last sent to Watchers A, G,  
> Document Fred E last sent to WatchersB , H
> Document Fred D last sent to Watchers C, K, R
> Document Fred C last sent to Watcher D, P,
> Document Fred B last sent to Watcher E, M
> Document Fred A last sent to Watcher F
>
> How many versions of Fred's unfiltered presence document do we need to
> keep ?
>

Looks like you are proposing 6 ;-). If I were to implement this (which
is btw. quite challenging), I would probably maintain only one document,
and the "trigger state" per watcher could be kept e.g. within the
watchers filter rule document, i.e. it could be e.g. an additional
attribute value within the <changed> element. But this is of course an
implementation issue. So imo keeping this "state information" does not
mean that you have to maintain the full published information.
Definitely this is additional state information to remember but I doubt
that it is not a major issue considering all the other tasks that you
have to implement. Another story is whether the text needs clarification
or not.
br,
Jari

--=_alternative 00546BF28025712B_=-- --===============0552787875== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0552787875==-- From simple-bounces@ietf.org Wed Mar 08 14:02:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3vh-000893-OV; Wed, 08 Mar 2006 14:02:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3vg-00088y-4s for simple@ietf.org; Wed, 08 Mar 2006 14:02:36 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH3vf-0004Im-AM for simple@ietf.org; Wed, 08 Mar 2006 14:02:36 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 5B591194467 for ; Wed, 8 Mar 2006 20:02:33 +0100 (CET) Received: from [192.168.1.72] ([192.168.1.72]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 20:00:59 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <0b0f8f0bb55b818609b0ab5f5cba1ee8@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Simple] Issue with comparisons for triggerring Date: Wed, 8 Mar 2006 20:02:59 +0100 To: "Sean Leahy" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 08 Mar 2006 19:00:59.0267 (UTC) FILETIME=[A313E530:01C642E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: "Jari Urpalainen , 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: , Errors-To: simple-bounces@ietf.org This simply will not work. Imagine I have filter that says: Tell me your mood when your location=20 has changed by 10km. This means 2 things: - a filter selecting - a filter for of value 10 Now, the first NOTIFY that comes will have the full state, which means=20= I get your mood as well as your location information (call it 1st XML=20 document). mood: happy location: Example st. You then move by 10km and I get a second NOTIFY. This time, I only get=20= your mood in the 2nd XML document sent to me because the filter is=20 applied. mood: happy If you look at the 2nd XML document that was sent after filtering, you=20= will not see any location information since the part of the=20 filter did not select it. You move by another 2km. A new NOTIFY needs to be generated (a 3rd XML=20= document). What you are suggesting is to compare that with the 2nd XML=20= document. This is not possible since the filter took out the location=20 information. However, if you look at the 2nd XML document that was=20 sent, but before the filter got applied to it, and compare it to the=20 3rd XML document before any filters were applied to it, it will be=20 possible to apply the trigger filter. What is delivered to the subscriber is orthogonal to what caused the=20 trigger. Therefore you cannot used the post filter xml documents to=20 compare for a trigger. Hisham On Mar 8, 2006, at 4:22 PM, Sean Leahy wrote: > > Jari and Hisham, > > I woud suggest changing the requirement to: > > "....... =A0Previous XML document in this context refers to the last = XML=20 > document that was delivered to that specific subscription." As Jari=20 > said, the rest is then an implementation issue. > > I think for example, Jari's solution works and the only overhead is=20 > the extra field 'last sent value' (per trigger) in the watcher's=20 > filter rule document (the latter doc has to be kept in any case). This=20= > field would be updated every time a doc was sent to=20= > the watcher. I think I was confused before believing that you need to=20= > remember all the info from the 'previous XML Document' - you only need=20= > to keep the value of the last sent value for each trigger. I blame the=20= > original requirement for confusing me. Why do we need the=20 > struck-through text - it only seems to confuse. > > "The element is used to identify the XML element or=20 > attribute, from the package specific XML document, whose value MUST=20 > change, compared to the "previous XML document", in order to activate=20= > the trigger and cause the content to be delivered. =A0Previous XML=20 > document in this context refers to the last XML document that was=20 > selected for delivery delivered to that specific subscription before=20= > any filter was applied to it." > > Regards, > Sean > > > > Jari Urpalainen > > 08/03/2006 13:52 > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0ext Sean Leahy = > =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0"Hisham Khartabil = simple@ietf.org > =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0Re: [Simple] Issue with = comparisons for=20 > triggerring > > > > On Wed, 2006-03-08 at 09:48 +0000, ext Sean Leahy wrote: > > > > Hisham Khartabil wrote: > > > > "Perhaps rephrasing the sentence to say the following will help you > > understand why I meant with my response. > > > > The 'previous XML documen' is "the last XML document that was > > selected > > for delivery to that specific subscription before any filter was > > applied to it and where the XML document was subsequently = delivered, > > after filtering, to the subscriber" > > > > What I'm trying to say is that the filters for triggers are used by > > comparing the current XML document with the XML document that was > > most > > recently sent to the subscriber, but before the filters were = applied > > to > > it." > > > > Sean Leahy> So "the last XML document that was selected > > for delivery to that specific subscription before any filter was > > applied to it" could be where the Status changed from 'A' to 'B' > > - this did not meet the criterion that =A0it "was subsequently > > delivered, > > after filtering, to the subscriber" (because the trigger is from = 'A' > > to 'C'). > > > > Sean Leahy> So now we have to look further back for the document > > that =A0 > > was the "the next last XML document that was selected > > for delivery to that specific subscription before any filter was > > applied to it" - this could be where the Status was marked as 'A'. > > i.e. it is > > the original document that was sent to the watcher in that case = this > > doc meets > > both the criteria. > > > > Sean Leahy> =A0However, in the case that it also was not sent, we = have > > to look > > further back again. > > > > Sean Leahy> Each subscription may have to go back to a different > > original =A0 > > unfiltered document. > > > > e.g. Presentity =3D Fred > > Document Fred F last sent to Watchers A, G, =A0 > > Document Fred E last sent to WatchersB , H > > Document Fred D last sent to Watchers C, K, R > > Document Fred C last sent to Watcher D, P, > > Document Fred B last sent to Watcher E, M > > Document Fred A last sent to Watcher F > > > > How many versions of Fred's unfiltered presence document do we need=20= > to > > keep ? > > > > Looks like you are proposing 6 ;-). If I were to implement this = (which > is btw. quite challenging), I would probably maintain only one=20 > document, > and the "trigger state" per watcher could be kept e.g. within the > watchers filter rule document, i.e. it could be e.g. an additional > attribute value within the element. But this is of course = an > implementation issue. So imo keeping this "state information" does = not > mean that you have to maintain the full published information. > Definitely this is additional state information to remember but I=20 > doubt > that it is not a major issue considering all the other tasks that you > have to implement. Another story is whether the text needs=20 > clarification > or not. > br, > Jari > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 08 16:20:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5vj-0004pc-6Y; Wed, 08 Mar 2006 16:10:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5bg-0007Dd-BV; Wed, 08 Mar 2006 15:50:04 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH5bf-0008Gx-8l; Wed, 08 Mar 2006 15:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k28Ko20e006047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FH5be-0002qa-Na; Wed, 08 Mar 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 08 Mar 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-pidf-format-06.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: , Errors-To: simple-bounces@ietf.org --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 : Presence Information Data format (PIDF) Extension for Partial Presence Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-pidf-format-06.txt Pages : 17 Date : 2006-3-8 The Presence Information Document Format (PIDF) specifies the baseline XML based format for describing presence information. One of the characteristic of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type which enables transporting of either only the changed parts or the full PIDF based presence information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-06.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-partial-pidf-format-06.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-partial-pidf-format-06.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: <2006-3-8124256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-pidf-format-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-8124256.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Wed Mar 08 16:28:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6Ct-0007zV-KS; Wed, 08 Mar 2006 16:28:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6Cs-0007xm-DD for simple@ietf.org; Wed, 08 Mar 2006 16:28:30 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH6Cr-0007l5-32 for simple@ietf.org; Wed, 08 Mar 2006 16:28:30 -0500 Received: from [172.17.2.252] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k28LSQA5001563 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 8 Mar 2006 15:28:28 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v746.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2BFE50CC-B6A8-433B-A733-AE104CF95B10@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Wed, 8 Mar 2006 15:28:26 -0600 To: "simple@ietf.org list" X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Simple] Fwd: [Sipping] XCAP notification split from config-framework 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: , Errors-To: simple-bounces@ietf.org fyi - in case you aren't watching SIPPING closely Begin forwarded message: > From: Rohan Mahy > Date: March 8, 2006 7:34:34 AM CST > To: Sipping List > Cc: Rohan Mahy , Allison Mankin , > Daniel Petrie , Gonzalo Camarillo > , Dean Willis > > Subject: [Sipping] XCAP notification split from config-framework > > Hi Folks, > > The -07 version of the config-framework had 3 XCAP-related > informative dependencies, but there were several pages of text > related to XCAP that should have been normative. This draft is > scheduled to go > to the IESG this week and this would cause an unknown delay. > > After discussions with Allison, we (Dan and I) decided to move the > XCAP-specific text to a separate draft. This is really an > administrative split. There is no technical difference between the > two documents and the one document Dan was going to submit > originally. While the new draft won't be submitted until the draft > blackout ends, a preview of the two drafts is available here: > > http://scm.sipfoundry.org/rep/ietf-drafts/sipping/config-framework/ > draft-ietf-sipping-config-framework-08.html > http://scm.sipfoundry.org/rep/ietf-drafts/sipping/config-framework/ > draft-ietf-sipping-config-framework-08.txt > > http://scm.sipfoundry.org/rep/ietf-drafts/sipping/config-framework/ > draft-ietf-sipping-xcap-config-00.html > http://scm.sipfoundry.org/rep/ietf-drafts/sipping/config-framework/ > draft-ietf-sipping-xcap-config-00.txt > > thanks, > -rohan > co-Chair SIPPING WG > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 08 16:54:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5fM-0004M4-Ae; Wed, 08 Mar 2006 15:53:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5bf-0007DQ-Tp; Wed, 08 Mar 2006 15:50:04 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH5bf-0008Gj-1k; Wed, 08 Mar 2006 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k28Ko20e006034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FH5be-0002ph-F0; Wed, 08 Mar 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 08 Mar 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xml-patch-ops-02.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: , Errors-To: simple-bounces@ietf.org --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 : An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors Author(s) : J. Urpalainen Filename : draft-ietf-simple-xml-patch-ops-02.txt Pages : 22 Date : 2006-3-8 Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. Updates to this data require transporting of the entire XML document between hosts, unless there's a mechanism that allows exchanging only the updates of XML documents. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic , and directives a set of patches can then be applied to update an existing XML document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xml-patch-ops-02.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-xml-patch-ops-02.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-xml-patch-ops-02.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: <2006-3-8122714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xml-patch-ops-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xml-patch-ops-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-8122714.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Wed Mar 08 17:20:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH71L-0000rE-Cu; Wed, 08 Mar 2006 17:20:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH71K-0000r1-Nm for simple@ietf.org; Wed, 08 Mar 2006 17:20:38 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH71K-0004Mj-EI for simple@ietf.org; Wed, 08 Mar 2006 17:20:38 -0500 Received: from [172.17.2.252] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k28MKb0g004746 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 8 Mar 2006 16:20:38 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v746.2) References: <1C6560CA-6E1C-46B5-A7AA-DFCC3F243BD2@estacado.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5822AD6A-D92A-40B7-9D97-8FFC271218D9@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Wed, 8 Mar 2006 16:20:36 -0600 To: "simple@ietf.org list" X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Simple] Strawman agenda: SIMPLE: IETF65 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: , Errors-To: simple-bounces@ietf.org All - We're in an unusual place for SIMPLE this time. We have a lot of big items that we've been pushing hard to get over the hump and they're all beginning to wrap up. We have a few new things to discuss, and its time to lay out the plan to pick up and finish those items we tabled during this last push. Reflecting this, here's the proposed agenda for our meeting Tuesday Afternoon III and IV in Dallas. 15m Chair update (will include status on msrp, common-policy, presence-rules, xcap-base) 5m Status on xml-patch and the drafts that depend on it (I'm expecting "done") 30m IMDN Open issues 5m PIDF-conn Open issues 30m niemi-simple-chat 15m xcap-profile 20m Roadmap for next round of work Two items warrant more detail: niemi-simple-chate is an individual submission that's been waiting for working group input. OMA has a dependency and asks after its progress regularly. It's time to cement working group commitment to taking this and finishing it, or rejecting it. Either way, it's time to give OMA something definitive. xcap-profile started a controversial discussion in Vancouver with very little list follow-through. Rohan believes he has changed this proposal to be only an optimization per the discussion. There are still some important questions raised that I expect to take real-time discussion to navigate. That said, this is the lowest priority of what I am proposing. If we need to adjust the schedule to make room for other conversations, this is the one that will have time taken away first. Let me know what you were expecting to discuss that you don't see here. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 08 18:31:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH880-0005dr-4W; Wed, 08 Mar 2006 18:31:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH87z-0005dm-F5 for simple@ietf.org; Wed, 08 Mar 2006 18:31:35 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH87w-0007wQ-NA for simple@ietf.org; Wed, 08 Mar 2006 18:31:35 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k28NVNc14414; Wed, 8 Mar 2006 18:31:23 -0500 (EST) 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] Strawman agenda: SIMPLE: IETF65 Date: Wed, 8 Mar 2006 17:31:22 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Strawman agenda: SIMPLE: IETF65 Thread-Index: AcZC/o8EP+X36Jq9SruhjHgEOjxyjwACIHLw From: "Mary Barnes" To: "Robert Sparks" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: 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: , Errors-To: simple-bounces@ietf.org On the neimi-simple-chat draft, I'm a bit puzzled as to how the state of that work is currently presented below (as "waiting for WG input"). The WG has discussed that draft in the past and fairly recently and I wasn't aware that the OMA demand for it was longstanding. Per the minutes from IETF-62 http://www.softarmor.com/simple/meets/ietf62/proceedings/simple62-sessio n2-minutes.html and per the recent discussions on the mailing list: http://www1.ietf.org/mail-archive/web/simple/current/msg06185.html the issue of nicknames is still a problem and it isn't just a SIMPLE WG decision. It impacts/overlaps with XCON and basic SIP work: http://www1.ietf.org/mail-archive/web/simple/current/msg06209.html=20 Now, if we're just going to push this through because of pressures from OMA, then let's admit that upfront and ensure that it's appropriately labeled as an OMA specific flavor of chat, rather than suggesting the WG has somehow been remiss at considering this work or providing constructive feedback.=20 Mary -----Original Message----- From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 Sent: Wednesday, March 08, 2006 4:21 PM To: simple@ietf.org list Subject: [Simple] Strawman agenda: SIMPLE: IETF65 All - We're in an unusual place for SIMPLE this time. We have a lot of big =20 items that we've been pushing hard to get over the hump and they're all =20 beginning to wrap up. We have a few new things to discuss, and its time to lay =20 out the plan to pick up and finish those items we tabled during this last push. Reflecting this, here's the proposed agenda for our meeting Tuesday Afternoon III and IV in Dallas. 15m Chair update (will include status on msrp, common-policy, =20 presence-rules, xcap-base) 5m Status on xml-patch and the drafts that depend on it (I'm =20 expecting "done") 30m IMDN Open issues 5m PIDF-conn Open issues 30m niemi-simple-chat 15m xcap-profile 20m Roadmap for next round of work Two items warrant more detail: niemi-simple-chate is an individual submission that's been =20 waiting for working group input. OMA has a dependency and asks after its =20 progress regularly. It's time to cement working group commitment to taking this =20 and finishing it, or rejecting it. Either way, it's time to give OMA something =20 definitive. xcap-profile started a controversial discussion in Vancouver =20 with very little list follow-through. Rohan believes he has changed this =20 proposal to be only an optimization per the discussion. There are still some =20 important questions raised that I expect to take real-time discussion to =20 navigate. That said, this is the lowest priority of what I am proposing. If we need to =20 adjust the schedule to make room for other conversations, this is the one that =20 will have time taken away first. Let me know what you were expecting to discuss that you don't see here. 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 Mar 08 18:50:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH8Q6-00067B-4E; Wed, 08 Mar 2006 18:50:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH8Pq-0005E7-C8; Wed, 08 Mar 2006 18:50:02 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH8Pq-0000Eo-0p; Wed, 08 Mar 2006 18:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k28No1vP010724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Mar 2006 23:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FH8Pp-0002Y8-IB; Wed, 08 Mar 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 08 Mar 2006 18:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-04.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: , Errors-To: simple-bounces@ietf.org --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 : Publication of Partial Presence Information Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-publish-04.txt Pages : 16 Date : 2006-3-8 The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bear a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitue a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-publish-04.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-partial-publish-04.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-partial-publish-04.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: <2006-3-8152037.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-publish-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-publish-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-8152037.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Thu Mar 09 00:26:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHDfj-0005eZ-2A; Thu, 09 Mar 2006 00:26:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHDfh-0005eU-Fx for simple@ietf.org; Thu, 09 Mar 2006 00:26:45 -0500 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.43) id 1FHDfh-0003X6-4L for simple@ietf.org; Thu, 09 Mar 2006 00:26:45 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 08 Mar 2006 21:26:44 -0800 X-IronPort-AV: i="4.02,177,1139212800"; d="scan'208"; a="413803206:sNHT31284332" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k295QiGv017503 for ; Wed, 8 Mar 2006 21:26:44 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 00:26:44 -0500 Received: from [192.168.1.101] ([10.86.240.100]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 00:26:43 -0500 Message-ID: <440FBC93.5050700@cisco.com> Date: Thu, 09 Mar 2006 00:26:43 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 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-OriginalArrivalTime: 09 Mar 2006 05:26:43.0817 (UTC) FILETIME=[0D5F9590:01C6433A] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [Simple] updated presence-rules 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: , Errors-To: simple-bounces@ietf.org I've submitted an updated to the presence-rules draft. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-simple-presence-rules-05.txt The main changes are to align with the latest common policy and to fix bugs. I did a really thorough comb through the draft, doing detailed comparisons with rpid and common-policy to make sure everything was aligned. This review did pop out some bugs. The full set of changes is below. One change I did NOT make, was to define a new MIME type for presence authorization documents. This had been suggested in some mail discussions over the last month or so, without clear consensus. I believe it is a mistake to try to define a new MIME type for presence rules separate from that of common policy. The reason is that I envision policy documents that contain rules from pres-rules, but also from other extensions to common policy. Indeed, consider geolocation. We have a mechanism for representing geolocatio in presence (pidf-lo), so one can imagine a presence document that contains BOTH geo-location and all kinds of RPID data, and one would want a SINGLE authorization document that provides rules covering both types of data. Its trivial to incorporate the policies in draft-ietf-geopriv-policy-08.txt into a pres-rules document. But, if each of these defines its own MIME type, it draws harder lines between them, and I think thats a mistake. Another reason I didnt make the change is, we have discussed this in the past. Pres-rules has effectively been done for a while, and I'm loathe to change anything at this point unless its just broken. Changing MIME types to a pres-rules specific one is not fixing a bug, and thus I think we should avoid these kinds of design changes. I believe this document is quite ready for WGLC (I dont think its had one?), and it makes sense to do that along with common policy which is going through its own WGLC now. Here are the full set of changes: * fixed bug reported on the list, which had the wrong repitition values for provide-devices and provide-persons * updated section on defining the XCAP usage; was missing some required sections from xcap, and in particular, the default namespace when used with xcap. THis default is urn:ietf:params:xml:ns:pres-rules. * aligned with XCAP on usage of the filename 'index' when there is a single authorization document * added back component-id and sub-handling to schema; somehow these got accidentally deleted many versions back, though they were in my version of the schema edited with xml-spy, they somehow didnt get into the document. How this happened is a complete mystery to me. * changed integral values of sub-handling to 0,10,20,30 instead of 0,1,2,3, to allow for new values to be inserted inbetween downstream. * changed integral values of provide-user-input from 0,1,2,3 to 0,10,20,30 for the same reason * changed and to and , to sync up with the final conclusion on this in the data model and rpid * clarified that the provide-note permission applies only to the top-level notes in person, device and tuple, NOT the notes embedded within attributes themselves (such as ). * fixed broken example that wasnt compiling * cleaned up some remnants of references to substitution groups in the text; we eliminated those from the schema some time back Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 09 05:28:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHINw-0006f5-Ck; Thu, 09 Mar 2006 05:28:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHINv-0006dX-2M for simple@ietf.org; Thu, 09 Mar 2006 05:28:43 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHINs-0004vC-T3 for simple@ietf.org; Thu, 09 Mar 2006 05:28:42 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 0D18219447A for ; Thu, 9 Mar 2006 11:28:39 +0100 (CET) Received: from [192.168.1.39] ([192.168.1.39]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 11:27:04 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Strawman agenda: SIMPLE: IETF65 Date: Thu, 9 Mar 2006 11:29:05 +0100 To: "Mary Barnes" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 09 Mar 2006 10:27:04.0730 (UTC) FILETIME=[02ACAFA0:01C64364] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: simple@ietf.orgWG, 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: , Errors-To: simple-bounces@ietf.org Mary, These issues you bring up are exactly the ones we hope to talk about and conclude on during the SIMPLE meeting. Thanks, Hisham On Mar 9, 2006, at 12:31 AM, Mary Barnes wrote: > On the neimi-simple-chat draft, I'm a bit puzzled as to how the state > of > that work is currently presented below (as "waiting for WG input"). > The > WG has discussed that draft in the past and fairly recently and I > wasn't > aware that the OMA demand for it was longstanding. Per the minutes > from > IETF-62 > http://www.softarmor.com/simple/meets/ietf62/proceedings/simple62- > sessio > n2-minutes.html > and per the recent discussions on the mailing list: > http://www1.ietf.org/mail-archive/web/simple/current/msg06185.html > the issue of nicknames is still a problem and it isn't just a SIMPLE WG > decision. It impacts/overlaps with XCON and basic SIP work: > http://www1.ietf.org/mail-archive/web/simple/current/msg06209.html > > Now, if we're just going to push this through because of pressures from > OMA, then let's admit that upfront and ensure that it's appropriately > labeled as an OMA specific flavor of chat, rather than suggesting the > WG > has somehow been remiss at considering this work or providing > constructive feedback. > > Mary > > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: Wednesday, March 08, 2006 4:21 PM > To: simple@ietf.org list > Subject: [Simple] Strawman agenda: SIMPLE: IETF65 > > > All - > > We're in an unusual place for SIMPLE this time. We have a lot of big > items > that we've been pushing hard to get over the hump and they're all > beginning > to wrap up. We have a few new things to discuss, and its time to lay > out the plan > to pick up and finish those items we tabled during this last push. > > Reflecting this, here's the proposed agenda for our meeting > Tuesday Afternoon III and IV in Dallas. > > 15m Chair update (will include status on msrp, common-policy, > presence-rules, xcap-base) > 5m Status on xml-patch and the drafts that depend on it > (I'm > expecting "done") > 30m IMDN Open issues > 5m PIDF-conn Open issues > 30m niemi-simple-chat > 15m xcap-profile > 20m Roadmap for next round of work > > > Two items warrant more detail: > > niemi-simple-chate is an individual submission that's been > waiting for working > group input. OMA has a dependency and asks after its > progress regularly. > It's time to cement working group commitment to taking this > and finishing it, > or rejecting it. Either way, it's time to give OMA something > definitive. > > xcap-profile started a controversial discussion in Vancouver > with very little > list follow-through. Rohan believes he has changed this > proposal to be only > an optimization per the discussion. There are still some > important questions > raised that I expect to take real-time discussion to > navigate. That said, this is > the lowest priority of what I am proposing. If we need to > adjust the schedule > to make room for other conversations, this is the one that > will have time taken > away first. > > Let me know what you were expecting to discuss that you don't see here. > > 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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 09 07:40:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKRh-0007hB-HW; Thu, 09 Mar 2006 07:40:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKRg-0007g9-JH for simple@ietf.org; Thu, 09 Mar 2006 07:40:44 -0500 Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHKRf-0000JF-CC for simple@ietf.org; Thu, 09 Mar 2006 07:40:44 -0500 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id k29CYIpD002280; Thu, 9 Mar 2006 12:40:37 GMT (envelope-from Sean.Leahy@marconi.com) To: "Hisham Khartabil Subject: Re: [Simple] Issue with comparisons for triggerring MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Sean Leahy" Date: Thu, 9 Mar 2006 12:02:54 +0000 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 09/03/2006 12:39:58, Serialize complete at 09/03/2006 12:39:58 X-Spam-Score: 0.1 (/) X-Scan-Signature: d273fad2623d4a35a7bb17d92c76f399 Cc: Jari Urpalainen , 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: , Content-Type: multipart/mixed; boundary="===============0589600147==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============0589600147== Content-Type: multipart/alternative; boundary="=_alternative 00422EC88025712C_=" This is a multipart message in MIME format. --=_alternative 00422EC88025712C_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please see my comments Sean 09/03/06=20 Hisham Khartabil 08/03/2006 19:02 =20 To: "Sean Leahy" cc: simple@ietf.org, "Jari Urpalainen filter selecting - a filter for of value 10 Now, the first NOTIFY that comes will have the full state, which means=20 I get your mood as well as your location information (call it 1st XML=20 document). mood: happy location: Example st. You then move by 10km and I get a second NOTIFY. This time, I only get=20 your mood in the 2nd XML document sent to me because the filter is=20 applied. mood: happy If you look at the 2nd XML document that was sent after filtering, you=20 will not see any location information since the part of the=20 filter did not select it. Sean 09/03/06 Agreed but that is because the watcher explicitly excluded it. Surely the the watcher could have asked for: - a filter selecting and - a filter for of value 10 Hisham wrote You move by another 2km. A new NOTIFY needs to be generated=20 (a 3rd XML=20 document). What you are suggesting is to compare that with the 2nd XML=20 document. This is not possible since the filter took out the location=20 information. However, if you look at the 2nd XML document that was=20 sent, but before the filter got applied to it, and compare it to the=20 3rd XML document before any filters were applied to it, it will be=20 possible to apply the trigger filter. Sean 09/03/06 No I do not think Jari or I suggested the comparison you desc= ribe. The latest xml document is always selected as the raw data (no point in=20 using out of date info). Then when the filtering is done we look at what was the = 'last triggering value'. The result in your example is first the full state got delivered: mood: happy location: Example st. (and the location value of 'Example st' is stored as the 'last triggering=20 value'=20 in the local copy of the watcher's filter rule document) Next the following got delivered: either: mood: happy location: Example st + 10km=20 (if location is desired i.e. 'included' in the flter). or just: mood: happy (if location not desired) (In either case the location value of 'Example st + 10 km' is stored as=20 the=20 'last triggering value' in the local copy of the watcher's filter rule=20 document) Next=20 mood: happy location: Example st + 12km=20 is originally selected but then not delivered because the filtering=20 determines that 12km - 10km does not meet the criterion for sending it (=20 of value 10). Hisham What is delivered to the subscriber is orthogonal to what caused=20 the=20 trigger. Therefore you cannot used the post filter xml documents to=20 compare for a trigger. Sean 09/03/06 As I have tried to demonstrate all we have to do is replace '= last sent=20 value' with 'last triggering value' to take account of the case that the=20 trigger operates on a different element to the 'included' element. Both elements are always in the raw document it is just necessary to=20 examine the triggers as the first part of filtering (before any elements=20 used for triggering can get filtered out). Are we not at risk of going down too much into implementation detail with=20 this discussion now ? Sean Hisham On Mar 8, 2006, at 4:22 PM, Sean Leahy wrote: > > Jari and Hisham, > > I woud suggest changing the requirement to: > > "....... =A0Previous XML document in this context refers to the last XML = > document that was delivered to that specific subscription." As Jari=20 > said, the rest is then an implementation issue. > > I think for example, Jari's solution works and the only overhead is=20 > the extra field 'last sent value' (per trigger) in the watcher's=20 > filter rule document (the latter doc has to be kept in any case). This=20 > field would be updated every time a doc was sent to=20 > the watcher. I think I was confused before believing that you need to=20 > remember all the info from the 'previous XML Document' - you only need=20 > to keep the value of the last sent value for each trigger. I blame the=20 > original requirement for confusing me. Why do we need the=20 > struck-through text - it only seems to confuse. > > "The element is used to identify the XML element or=20 > attribute, from the package specific XML document, whose value MUST=20 > change, compared to the "previous XML document", in order to activate=20 > the trigger and cause the content to be delivered. =A0Previous XML=20 > document in this context refers to the last XML document that was=20 > selected for delivery delivered to that specific subscription before=20 > any filter was applied to it." > > Regards, > Sean > > > > Jari Urpalainen > > 08/03/2006 13:52 > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0ext Sean Leahy > =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0"Hisham Khartabil simple@ietf.org > =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0Re: [Simple] Issue with compariso= ns for=20 > triggerring > > > > On Wed, 2006-03-08 at 09:48 +0000, ext Sean Leahy wrote: > > > > Hisham Khartabil wrote: > > > > "Perhaps rephrasing the sentence to say the following will help you > > understand why I meant with my response. > > > > The 'previous XML documen' is "the last XML document that was > > selected > > for delivery to that specific subscription before any filter was > > applied to it and where the XML document was subsequently delivered, > > after filtering, to the subscriber" > > > > What I'm trying to say is that the filters for triggers are used by > > comparing the current XML document with the XML document that was > > most > > recently sent to the subscriber, but before the filters were applied > > to > > it." > > > > Sean Leahy> So "the last XML document that was selected > > for delivery to that specific subscription before any filter was > > applied to it" could be where the Status changed from 'A' to 'B' > > - this did not meet the criterion that =A0it "was subsequently > > delivered, > > after filtering, to the subscriber" (because the trigger is from 'A' > > to 'C'). > > > > Sean Leahy> So now we have to look further back for the document > > that =A0 > > was the "the next last XML document that was selected > > for delivery to that specific subscription before any filter was > > applied to it" - this could be where the Status was marked as 'A'. > > i.e. it is > > the original document that was sent to the watcher in that case this > > doc meets > > both the criteria. > > > > Sean Leahy> =A0However, in the case that it also was not sent, we have > > to look > > further back again. > > > > Sean Leahy> Each subscription may have to go back to a different > > original =A0 > > unfiltered document. > > > > e.g. Presentity =3D Fred > > Document Fred F last sent to Watchers A, G, =A0 > > Document Fred E last sent to WatchersB , H > > Document Fred D last sent to Watchers C, K, R > > Document Fred C last sent to Watcher D, P, > > Document Fred B last sent to Watcher E, M > > Document Fred A last sent to Watcher F > > > > How many versions of Fred's unfiltered presence document do we need=20 > to > > keep ? > > > > Looks like you are proposing 6 ;-). If I were to implement this (which > is btw. quite challenging), I would probably maintain only one=20 > document, > and the "trigger state" per watcher could be kept e.g. within the > watchers filter rule document, i.e. it could be e.g. an additional > attribute value within the element. But this is of course an > implementation issue. So imo keeping this "state information" does not > mean that you have to maintain the full published information. > Definitely this is additional state information to remember but I=20 > doubt > that it is not a major issue considering all the other tasks that you > have to implement. Another story is whether the text needs=20 > clarification > or not. > br, > Jari > > > --=_alternative 00422EC88025712C_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Please see my comments Sean 09/03/06=



Hisham Khartabil <hisham.khart= abil@telio.no>

08/03/2006 19:02

       
        To: &nbs= p;      "Sean Leahy" <Sean.Leahy@marconi.com>= ;
        cc: &nbs= p;      simple@ietf.org, "Jari Urpalainen <jari.urpa= lainen"
        Subject:=        Re: [Simple] Issue with comparisons for trigger= ring



This simply will not work.

Sean 09/03/06 O.K. but all we have to do is replace 'last sent value= ' with 'last triggering value' to take account of the case that the trigger= operates on a different element to the 'included' element.

Hisham wrote Imagine I have filter that says: Tell me your mood when your l= ocation
has changed by 10km.

Sean 09/03/06 Note: This could have been "Tell me your mood AND= LOCATION when your location
has changed by 10km" but it is not.

Hisham wrote This means 2 things:
- a <what> filter selecting <mood>
- a <trigger> filter for <changed-by> of value 10

Now, the first NOTIFY that comes will have the full state, which means
I get your mood as well as your location information (call it 1st XML
document).

mood: happy
location: Example st.

You then move by 10km and I get a second NOTIFY. This time, I only get
your mood in the 2nd XML document sent to me because the filter is
applied.

mood: happy

If you look at the 2nd XML document that was sent after filtering, you
will not see any location information since the <what> part of the filter did not select it.

Sean 09/03/06 Agreed but that is because the watcher explicitly excl= uded it.
Surely the the watcher could have a= sked for:

- a <what> filter selecting &= lt;mood> and <location>
- a <trigger> filter for <location> <changed-by> of value= 10

Hisham wrote You move by another 2km.  A new NOTIFY needs to be genera= ted (a 3rd XML
document). What you are suggesting is to compare that with the 2nd XML
document. This is not possible since the filter took out the location
information. However, if you look at the 2nd XML document that was
sent, but before the filter got applied to it, and compare it to the
3rd XML document before any filters were applied to it, it will be
possible to apply the trigger filter.

Sean 09/03/06 No I do not think Jari or I suggested the comparison y= ou describe.
The latest xml document is always s= elected as the raw data (no point in using
out of date info). Then when the fi= ltering is done we look at what was the
'last triggering value'.

The result in your example is first= the full state got delivered:

mood: happy
location: Example st.

(and the location value of 'Example= st' is stored as the 'last triggering value'
in the local copy of the watcher's = filter rule document)

Next the following got delivered:

either:

mood: happy
location: Example st + 10km
(if location is desired i.e. 'inclu= ded' in the flter).

or just:
mood: happy (if location not desire= d)

(In either case the location value = of 'Example st + 10 km' is stored as the
'last triggering value' in the loca= l copy of the watcher's filter rule document)

Next

mood: happy
location: Example st + 12km
is originally selected but then not= delivered because the filtering determines
that 12km - 10km does not meet the = criterion for sending it (<changed-by> of value 10).

Hisham What is delivered to the subscriber is orthogonal to what caused the=
trigger. Therefore you cannot used the post filter xml documents to
compare for a trigger.

Sean 09/03/06 As I have tried to demonstrate all we have to do is re= place 'last sent value' with 'last triggering value' to take account of the= case that the trigger operates on a different element to the 'included' el= ement.
Both elements are always in the raw= document it is just necessary to examine the triggers as the first part of= filtering (before any elements used for triggering can get filtered out).<= /font>

Are we not at risk of going down to= o much into implementation detail with this discussion now ?

Sean

Hisham

On Mar 8, 2006, at 4:22 PM, Sean Leahy wrote:

>
> Jari and Hisham,
>
> I woud suggest changing the requirement to:
>
> "....... =A0Previous XML document in this context refers to the l= ast XML
> document that was delivered to that specific subscription." As Ja= ri
> said, the rest is then an implementation issue.
>
> I think for example, Jari's solution works and the only overhead is > the extra field 'last sent value' (per trigger) in the watcher's
> filter rule document (the latter doc has to be kept in any case). This=
> field <or an equivalent> would be updated every time a doc was s= ent to
> the watcher. I think I was confused before believing that you need to =
> remember all the info from the 'previous XML Document' - you only need=
> to keep the value of the last sent value for each trigger. I blame the=
> original requirement for confusing me. Why do we need the
> struck-through text - it only seems to confuse.
>
> "The <changed> element is used to identify the XML element = or
> attribute, from the package specific XML document, whose value MUST > change, compared to the "previous XML document", in order to= activate
> the trigger and cause the content to be delivered. =A0Previous XML
> document in this context refers to the last XML document that was
> selected for delivery delivered to that specific subscription before <= br> > any filter was applied to it."
>
> Regards,
> Sean
>
>
>
> Jari Urpalainen <jari.urpalainen@nokia.com>
>
> 08/03/2006 13:52
> =A0 =A0 =A0 =A0
> =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0ext Sean Leahy <Sean.Leahy@marco= ni.com>
> =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0"Hisham Khartabil <hisham.k= hartabil",
> simple@ietf.org
> =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0Re: [Simple] Issue with compar= isons for
> triggerring
>
>
>
> On Wed, 2006-03-08 at 09:48 +0000, ext Sean Leahy wrote:
>  >
>  > Hisham Khartabil wrote:
>  >
>  > "Perhaps rephrasing the sentence to say the following = will help you
>  > understand why I me= ant with my response.
>  >
>  > The 'previous XML documen' is "the last XML document t= hat was
>  > selected
>  > for delivery to that specific subscription before any filte= r was
>  > applied to it and where the XML document was subsequently d= elivered,
>  > after filtering, to the subscriber"
>  >
>  > What I'm trying to say is that the filters for triggers are= used by
>  > comparing the current XML document with the XML document th= at was
>  > most
>  > recently sent to the subscriber, but before the filters wer= e applied
>  > to
>  > it."
>  >
>  > Sean Leahy> So "the last XML document that was sele= cted
>  > for delivery to that specific subscription before any filte= r was
>  > applied to it" could be where the Status changed from = 'A' to 'B'
>  > - this did not meet the criterion that =A0it "was subs= equently
>  > delivered,
>  > after filtering, to the subscriber" (because the trigg= er is from 'A'
>  > to 'C').
>  >
>  > Sean Leahy> So now we have to look further back for the = document
>  > that =A0
>  > was the "the next last XML document that was selected<= br> >  > for delivery to that specific subscription before any filte= r was
>  > applied to it" - this could be where the Status was ma= rked as 'A'.
>  > i.e. it is
>  > the original document that was sent to the watcher in that = case this
>  > doc meets
>  > both the criteria.
>  >
>  > Sean Leahy> =A0However, in the case that it also was not= sent, we have
>  > to look
>  > further back again.
>  >
>  > Sean Leahy> Each subscription may have to go back to a d= ifferent
>  > original =A0
>  > unfiltered document.
>  >
>  > e.g. Presentity =3D Fred
>  > Document Fred F last sent to Watchers A, G, =A0
>  > Document Fred E last sent to WatchersB , H
>  > Document Fred D last sent to Watchers C, K, R
>  > Document Fred C last sent to Watcher D, P,
>  > Document Fred B last sent to Watcher E, M
>  > Document Fred A last sent to Watcher F
>  >
>  > How many versions of Fred's unfiltered presence document do= we need
> to
>  > keep ?
>  >
>
>  Looks like you are proposing 6 ;-). If I were to implement this = (which
>  is btw. quite challenging), I would probably maintain only one <= br> > document,
>  and the "trigger state" per watcher could be kept e.g.= within the
>  watchers filter rule document, i.e. it could be e.g. an addition= al
>  attribute value within the <changed> element. But this is = of course an
>  implementation issue. So imo keeping this "state informatio= n" does not
>  mean that you have to maintain the full published information. >  Definitely this is additional state information to remember but = I
> doubt
>  that it is not a major issue considering all the other tasks tha= t you
>  have to implement. Another story is whether the text needs
> clarification
>  or not.
>  br,
>  Jari
>
>
>

--=_alternative 00422EC88025712C_=-- --===============0589600147== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0589600147==-- From simple-bounces@ietf.org Thu Mar 09 08:33:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHLGN-00071U-VF; Thu, 09 Mar 2006 08:33:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHLGA-0006pf-2g for simple@ietf.org; Thu, 09 Mar 2006 08:32:54 -0500 Received: from smtpoutuk01.marconi.com ([128.87.251.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHLG9-0001ls-6f for simple@ietf.org; Thu, 09 Mar 2006 08:32:53 -0500 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk01.marconi.com (8.12.11/8.12.11) with ESMTP id k29DTmhX010853 for ; Thu, 9 Mar 2006 13:32:47 GMT (envelope-from Sean.Leahy@marconi.com) To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Sean Leahy" Date: Thu, 9 Mar 2006 13:01:21 +0000 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 09/03/2006 13:32:08, Serialize complete at 09/03/2006 13:32:08 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Subject: [Simple] Query on Request URI of PUBLISH vs 'pres' URL of publishing entity 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="===============0419217194==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============0419217194== Content-Type: multipart/alternative; boundary="=_alternative 004789038025712C_=" This is a multipart message in MIME format. --=_alternative 004789038025712C_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can anyone answer my previous questions as below ?: - Is my understanding correct that the model allows for a separation of=20 the subject entity (identified by the Request-URI) and the publishing=20 entity (identified by the 'pres' URL)?=20 - If there is no separation between the subject and the publisher=20 intended, then can it be said that the Request URI of a PUBLISH request=20 must always be the same as the 'pres' URL (in the PIDF in the PUBLISH=20 request) ? Sean Leahy ----- Forwarded by Sean Leahy/MAIN/MC1 on 09/03/2006 12:58 ----- Sean Leahy 06/03/2006 11:06 =20 To: simple@ietf.org cc:=20 Subject: Request URI of PUBLISH vs 'pres' URL of publishing = entity There seems to be a contradiction within RFCs 3903, 3863 and=20 draft-rosenburg-simple-presence-processing-model-01. The Request-URI of a PUBLISH request contains the information necessary to = route the request to the Presence Server and identifies the resource whose = event state is to be published [RFC 3903]. Thus the PUBLISH request is=20 sent to the Presence Server that composes the presence state bound to the=20 address in the Request-URI. The presence element of a Presence Information Data Format document (PIDF) = [RFC 3863] must have an 'entity' attribute. The value of the 'entity'=20 attribute is the 'pres' URL of the presentity publishing this document.=20 i.e. the 'pres' URL appears to identify the publisher rather than the=20 subject of the presence document (these may or may not be the same). Is my understanding correct that the model allows for a separation of the=20 subject entity (identified by the Request-URI) and the publishing entity=20 (identified by the 'pres' URL)?=20 If so, I would have expected 'A Processing Model for Presence' (draft-rosen= burg-simple-presence-processing-model-01) to show that the collection of ev= ent state centres around the=20 Request-URI but in fact it identifies "the set of documents whose "entity" = attribute in the element in the presence document is the same=20 as that of the presentity." i.e. it appears to centre around the 'pres'=20 URL (in the PIDF in the PUBLISH request) rather than the Request-URI. This seems to contradict the position that the 'pres' URL identifies the=20 publisher rather than the subject of the presence document or at least=20 eliminates the idea that there is a separation of the subject entity=20 (identified by the Request-URI) and the publishing entity (identified by=20 the 'pres' URL). Please can you clarify which position is correct ?=20 If there is no separation between the subject and the publisher intended,=20 then can it be said the the Request URI of a PUBLISH request must always=20 be the same as the 'pres' URL (in the PIDF in the PUBLISH request) ? --=_alternative 004789038025712C_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Can anyone answer my previous questi= ons as below ?:

- Is my understanding correct that t= he model allows for a separation of the subject entity (identified by the R= equest-URI) and the publishing entity (identified by the 'pres' URL)?

- If there is no separation between = the subject and the publisher intended, then can it be said that the Reques= t URI of a PUBLISH request must always be the same as the  'pres' URL = (in the PIDF in the PUBLISH request)  ?

Sean Leahy


----- Forwarded by S= ean Leahy/MAIN/MC1 on 09/03/2006 12:58 -----
Sean Leahy

06/03/2006 11:06

       
        To: &nbs= p;      simple@ietf.org
        cc: &nbs= p;      
        Subject:=        Request URI of PUBLISH vs 'pres' URL of publish= ing entity


There seems to be a contradiction wi= thin RFCs 3903, 3863 and draft-rosenburg-simple-presence-processing-model-0= 1.

The Request-URI of a PUBLISH request= contains the information necessary to route the request to the Presence Se= rver and identifies the resource whose event state is to be published [RFC = 3903]. Thus the PUBLISH request is sent to the Presence Server that compose= s the presence state bound to the address in the Request-URI.

The presence element of a Presence I= nformation Data Format document (PIDF) [RFC 3863] must have an 'entity' att= ribute.  The value of the 'entity' attribute is the 'pres' URL of the = presentity publishing this document. i.e. the 'pres' URL appears to identif= y the publisher rather than the subject of the presence document (these may= or may not be the same).

Is my understanding correct that the= model allows for a separation of the subject entity (identified by the Req= uest-URI) and the publishing entity (identified by the 'pres' URL)?

If so, I would have expected 'A Proc= essing Model for Presence' (draft-rosenburg-simple-presence-processing-m= odel-01) to show that the collection of event state centres around the = Request-URI but in fact it identifies "the set of documents whose &quo= t;entity" attribute in the <presence> element in the presence do= cument is the same as that of the presentity." i.e. it appears to cent= re around the 'pres' URL (in the PIDF in the PUBLISH request) rather than t= he Request-URI.

This seems to contradict the positio= n that the 'pres' URL identifies the publisher rather than the subject of t= he presence document or at least eliminates the idea that there is a separa= tion of the subject entity (identified by the Request-URI) and the publishi= ng entity (identified by the 'pres' URL).

Please can you clarify which positio= n is correct ?

If there is no separation between th= e subject and the publisher intended, then can it be said the the Request U= RI of a PUBLISH request must always be the same as the  'pres' URL (in= the PIDF in the PUBLISH request)  ?
--=_alternative 004789038025712C_=-- --===============0419217194== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0419217194==-- From simple-bounces@ietf.org Thu Mar 09 09:15:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHLuz-0001Wu-Tq; Thu, 09 Mar 2006 09:15:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHLuy-0001So-4a for simple@ietf.org; Thu, 09 Mar 2006 09:15:04 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHLux-0003FH-Kj for simple@ietf.org; Thu, 09 Mar 2006 09:15:04 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k29EDKZZ014577; Thu, 9 Mar 2006 16:13:23 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 16:15:02 +0200 Received: from [172.21.35.210] ([172.21.35.210]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 9 Mar 2006 16:15:01 +0200 Message-ID: <44103865.5080403@nokia.com> Date: Thu, 09 Mar 2006 16:15:01 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Sean Leahy Subject: Re: [Simple] Query on Request URI of PUBLISH vs 'pres' URL of publishing entity References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2006 14:15:01.0879 (UTC) FILETIME=[DAE40070:01C64383] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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: , Errors-To: simple-bounces@ietf.org Hi Sean, I can imagine a useful scenario where the Request-URI and the entity attribute of the presence document weren't the same. For example, I might have an alias address for myself at forever.example.com, where I publish my presence documents using whatever identity my current ISP is offering me, while at work: PUBLISH sip:aki@forever.example.com SIP/2.0 ... To: From: ;tag=skd8iehdl ... ... However, this sort of setup would require that the system duly authorizes such "fourth-party" publications. It's maybe a bit far fetched, but certainly allowed. Cheers, Aki ext Sean Leahy wrote: > > Can anyone answer my previous questions as below ?: > > - Is my understanding correct that the model allows for a separation of > the subject entity (identified by the Request-URI) and the publishing > entity (identified by the 'pres' URL)? > > - If there is no separation between the subject and the publisher > intended, then can it be said that the Request URI of a PUBLISH request > must always be the same as the 'pres' URL (in the PIDF in the PUBLISH > request) ? > > Sean Leahy > > > ----- Forwarded by Sean Leahy/MAIN/MC1 on 09/03/2006 12:58 ----- > *Sean Leahy* > > 06/03/2006 11:06 > > > To: simple@ietf.org > cc: > Subject: Request URI of PUBLISH vs 'pres' URL of > publishing entity > > > > There seems to be a contradiction within RFCs 3903, 3863 and > draft-rosenburg-simple-presence-processing-model-01. > > The Request-URI of a PUBLISH request contains the information necessary > to route the request to the Presence Server and identifies the resource > whose event state is to be published [RFC 3903]. Thus the PUBLISH > request is sent to the Presence Server that composes the presence state > bound to the address in the Request-URI. > > The presence element of a Presence Information Data Format document > (PIDF) [RFC 3863] must have an 'entity' attribute. The value of the > 'entity' attribute is the 'pres' URL of the presentity publishing this > document. i.e. the 'pres' URL appears to identify the publisher rather > than the subject of the presence document (these may or may not be the > same). > > Is my understanding correct that the model allows for a separation of > the subject entity (identified by the Request-URI) and the publishing > entity (identified by the 'pres' URL)? > > If so, I would have expected 'A Processing Model for Presence' > (/draft-rosenburg-simple-presence-processing-model-01/) to show that the > collection of event state centres around the Request-URI but in fact it > identifies "the set of documents whose "entity" attribute in the > element in the presence document is the same as that of the > presentity." i.e. it appears to centre around the 'pres' URL (in the > PIDF in the PUBLISH request) rather than the Request-URI. > > This seems to contradict the position that the 'pres' URL identifies the > publisher rather than the subject of the presence document or at least > eliminates the idea that there is a separation of the subject entity > (identified by the Request-URI) and the publishing entity (identified by > the 'pres' URL). > > Please can you clarify which position is correct ? > > If there is no separation between the subject and the publisher > intended, then can it be said the the Request URI of a PUBLISH request > must always be the same as the 'pres' URL (in the PIDF in the PUBLISH > request) ? > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Mar 09 09:30:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHMA0-0005VW-Hh; Thu, 09 Mar 2006 09:30:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHM9x-0005VR-IX for simple@ietf.org; Thu, 09 Mar 2006 09:30:33 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHM9w-0003qO-5x for simple@ietf.org; Thu, 09 Mar 2006 09:30:33 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by test-iport-1.cisco.com with ESMTP; 09 Mar 2006 06:30:31 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k29EUR1p025583; Thu, 9 Mar 2006 06:30:31 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 09:30:29 -0500 Received: from [192.168.1.101] ([10.86.240.100]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 09:30:29 -0500 Message-ID: <44103C04.6070708@cisco.com> Date: Thu, 09 Mar 2006 09:30:28 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Leahy Subject: Re: [Simple] Query on Request URI of PUBLISH vs 'pres' URL of publishing entity References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2006 14:30:29.0402 (UTC) FILETIME=[03BCC7A0:01C64386] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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: , Errors-To: simple-bounces@ietf.org http://www.jdrosen.net/papers/draft-rosenberg-simple-presence-processing-model-01.txt talks about motivations for why you might want them different. The idea there is that the presence server is going to collect presence documents for the presentity in the entity attribute, and compose them together. However, presence inputs for that presentity can be generated from presence documents from other presentities too, in cases where they have some kind of relationship. Thus, I might want to send a PUBLISH request with URI A and entity with URI B if presence for presentity A requires state of presentity B. The PUBLISH URI is really used for routing; getting the presence document to the right place. HTH, Jonathan R. Sean Leahy wrote: > > Can anyone answer my previous questions as below ?: > > - Is my understanding correct that the model allows for a separation of > the subject entity (identified by the Request-URI) and the publishing > entity (identified by the 'pres' URL)? > > - If there is no separation between the subject and the publisher > intended, then can it be said that the Request URI of a PUBLISH request > must always be the same as the 'pres' URL (in the PIDF in the PUBLISH > request) ? > > Sean Leahy > > > ----- Forwarded by Sean Leahy/MAIN/MC1 on 09/03/2006 12:58 ----- > *Sean Leahy* > > 06/03/2006 11:06 > > > To: simple@ietf.org > cc: > Subject: Request URI of PUBLISH vs 'pres' URL of > publishing entity > > > > There seems to be a contradiction within RFCs 3903, 3863 and > draft-rosenburg-simple-presence-processing-model-01. > > The Request-URI of a PUBLISH request contains the information necessary > to route the request to the Presence Server and identifies the resource > whose event state is to be published [RFC 3903]. Thus the PUBLISH > request is sent to the Presence Server that composes the presence state > bound to the address in the Request-URI. > > The presence element of a Presence Information Data Format document > (PIDF) [RFC 3863] must have an 'entity' attribute. The value of the > 'entity' attribute is the 'pres' URL of the presentity publishing this > document. i.e. the 'pres' URL appears to identify the publisher rather > than the subject of the presence document (these may or may not be the > same). > > Is my understanding correct that the model allows for a separation of > the subject entity (identified by the Request-URI) and the publishing > entity (identified by the 'pres' URL)? > > If so, I would have expected 'A Processing Model for Presence' > (/draft-rosenburg-simple-presence-processing-model-01/) to show that the > collection of event state centres around the Request-URI but in fact it > identifies "the set of documents whose "entity" attribute in the > element in the presence document is the same as that of the > presentity." i.e. it appears to centre around the 'pres' URL (in the > PIDF in the PUBLISH request) rather than the Request-URI. > > This seems to contradict the position that the 'pres' URL identifies the > publisher rather than the subject of the presence document or at least > eliminates the idea that there is a separation of the subject entity > (identified by the Request-URI) and the publishing entity (identified by > the 'pres' URL). > > Please can you clarify which position is correct ? > > If there is no separation between the subject and the publisher > intended, then can it be said the the Request URI of a PUBLISH request > must always be the same as the 'pres' URL (in the PIDF in the PUBLISH > request) ? > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 09 10:36:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNBj-0002xk-E1; Thu, 09 Mar 2006 10:36:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNBi-0002xN-AQ for simple@ietf.org; Thu, 09 Mar 2006 10:36:26 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHNBg-0005lY-VG for simple@ietf.org; Thu, 09 Mar 2006 10:36:26 -0500 Received: from [172.17.2.252] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k29FaLHA007058 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 9 Mar 2006 09:36:23 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Simple] Strawman agenda: SIMPLE: IETF65 Date: Thu, 9 Mar 2006 09:36:20 -0600 To: Mary Barnes X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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: , Errors-To: simple-bounces@ietf.org Thanks for requesting clarification Mary. I didn't intend to suggest any particular decision around this topic, only that we need to make some concrete decisions soon. There has been discussion around elements of this draft in the past, but its been spread out (as you note below it impacts more than one working group's efforts) and I don't think it's captured the focus of the full working group. We've been pushing hard on other things, and Aki and Miguel have helped make sure we gave those other things cycles. The thread you point to below (I suggest starting at http://www1.ietf.org/mail-archive/web/simple/current/msg06164.html ) is the kind of conversation I intended to draw focus to. RjS On Mar 8, 2006, at 5:31 PM, Mary Barnes wrote: > On the neimi-simple-chat draft, I'm a bit puzzled as to how the > state of > that work is currently presented below (as "waiting for WG > input"). The > WG has discussed that draft in the past and fairly recently and I > wasn't > aware that the OMA demand for it was longstanding. Per the minutes > from > IETF-62 > http://www.softarmor.com/simple/meets/ietf62/proceedings/simple62- > sessio > n2-minutes.html > and per the recent discussions on the mailing list: > http://www1.ietf.org/mail-archive/web/simple/current/msg06185.html > the issue of nicknames is still a problem and it isn't just a > SIMPLE WG > decision. It impacts/overlaps with XCON and basic SIP work: > http://www1.ietf.org/mail-archive/web/simple/current/msg06209.html > > Now, if we're just going to push this through because of pressures > from > OMA, then let's admit that upfront and ensure that it's appropriately > labeled as an OMA specific flavor of chat, rather than suggesting > the WG > has somehow been remiss at considering this work or providing > constructive feedback. > > Mary > > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: Wednesday, March 08, 2006 4:21 PM > To: simple@ietf.org list > Subject: [Simple] Strawman agenda: SIMPLE: IETF65 > > > All - > > We're in an unusual place for SIMPLE this time. We have a lot of big > items > that we've been pushing hard to get over the hump and they're all > beginning > to wrap up. We have a few new things to discuss, and its time to lay > out the plan > to pick up and finish those items we tabled during this last push. > > Reflecting this, here's the proposed agenda for our meeting > Tuesday Afternoon III and IV in Dallas. > > 15m Chair update (will include status on msrp, common-policy, > presence-rules, xcap-base) > 5m Status on xml-patch and the drafts that depend on it > (I'm > expecting "done") > 30m IMDN Open issues > 5m PIDF-conn Open issues > 30m niemi-simple-chat > 15m xcap-profile > 20m Roadmap for next round of work > > > Two items warrant more detail: > > niemi-simple-chate is an individual submission that's been > waiting for working > group input. OMA has a dependency and asks after its > progress regularly. > It's time to cement working group commitment to taking this > and finishing it, > or rejecting it. Either way, it's time to give OMA something > definitive. > > xcap-profile started a controversial discussion in Vancouver > with very little > list follow-through. Rohan believes he has changed this > proposal to be only > an optimization per the discussion. There are still some > important questions > raised that I expect to take real-time discussion to > navigate. That said, this is > the lowest priority of what I am proposing. If we need to > adjust the schedule > to make room for other conversations, this is the one that > will have time taken > away first. > > Let me know what you were expecting to discuss that you don't see > here. > > 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 Thu Mar 09 11:35:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHO6a-0000Ow-FB; Thu, 09 Mar 2006 11:35:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHO6Y-0000KW-VR for simple@ietf.org; Thu, 09 Mar 2006 11:35:10 -0500 Received: from wproxy.gmail.com ([64.233.184.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHO6X-0007nC-EJ for simple@ietf.org; Thu, 09 Mar 2006 11:35:10 -0500 Received: by wproxy.gmail.com with SMTP id 37so690891wra for ; Thu, 09 Mar 2006 08:35:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=B5mO4N1KN4yAseiOWvsbqDnF79ts64U7nh3RRuo8JYnxF0Ys3YQpmfABPAPLtzAYSBjHsdDZGTi//TZnjUGA12DfNI618wpkgUjpbs70TCq8yPOYq4Il4tLODvGpKUGpvb1RSpR18PYqnGF9G8CGO3fzBh5qmKKu12rvCwZ7a8I= Received: by 10.65.83.9 with SMTP id k9mr1179137qbl; Thu, 09 Mar 2006 08:35:08 -0800 (PST) Received: by 10.65.115.16 with HTTP; Thu, 9 Mar 2006 08:35:08 -0800 (PST) Message-ID: Date: Thu, 9 Mar 2006 11:35:08 -0500 From: "Arjun Roychowdhury" To: "Jonathan Rosenberg" Subject: Re: [Simple] updated presence-rules draft In-Reply-To: <440FBC93.5050700@cisco.com> MIME-Version: 1.0 References: <440FBC93.5050700@cisco.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 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: , Content-Type: multipart/mixed; boundary="===============1698437503==" Errors-To: simple-bounces@ietf.org --===============1698437503== Content-Type: multipart/alternative; boundary="----=_Part_6922_21342339.1141922108944" ------=_Part_6922_21342339.1141922108944 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The part of this authorization I-D is very useful for authorization of 'any state sharing' - not just presence. My question, therefore, is that should the common-policy draft include, at the least, some of the clauses in its schema definition instead of leaving it open for others to extend ? Or, the presence-authorization draft makes its scope more general by saying the draft applies to a wide variety of state sharing, not limited to presence authorization. Specifically, irrespective of what we choose to share, we need a mechanism to specify authorization. Allow, Block, Confirm are fundamental actions. If I choose to implement common-policy, it leaves an open area for 'action' - and the only other draft I found which realizes 'action' is 'presence-authorization' which then says it is related to presence, whereas I feel this should apply to a wider scope. This only leaves the option of creating a new extension (which is not necessary), or using 'presence-authorization's ' spec which is again, primarily motivated for 'presence sharing' . regds arjun On 3/9/06, Jonathan Rosenberg wrote: > > I've submitted an updated to the presence-rules draft. Until it appears > in the archives, you can pick it up at: > > http://www.jdrosen.net/papers/draft-ietf-simple-presence-rules-05.txt > > The main changes are to align with the latest common policy and to fix > bugs. I did a really thorough comb through the draft, doing detailed > comparisons with rpid and common-policy to make sure everything was > aligned. This review did pop out some bugs. The full set of changes is > below. > > One change I did NOT make, was to define a new MIME type for presence > authorization documents. This had been suggested in some mail > discussions over the last month or so, without clear consensus. I > believe it is a mistake to try to define a new MIME type for presence > rules separate from that of common policy. The reason is that I envision > policy documents that contain rules from pres-rules, but also from other > extensions to common policy. Indeed, consider geolocation. We have a > mechanism for representing geolocatio in presence (pidf-lo), so one can > imagine a presence document that contains BOTH geo-location and all > kinds of RPID data, and one would want a SINGLE authorization document > that provides rules covering both types of data. Its trivial to > incorporate the policies in draft-ietf-geopriv-policy-08.txt into a > pres-rules document. But, if each of these defines its own MIME type, it > draws harder lines between them, and I think thats a mistake. > > Another reason I didnt make the change is, we have discussed this in the > past. Pres-rules has effectively been done for a while, and I'm loathe > to change anything at this point unless its just broken. Changing MIME > types to a pres-rules specific one is not fixing a bug, and thus I think > we should avoid these kinds of design changes. > > I believe this document is quite ready for WGLC (I dont think its had > one?), and it makes sense to do that along with common policy which is > going through its own WGLC now. > > > > Here are the full set of changes: > > > * fixed bug reported on the list, which had the wrong repitition > values for provide-devices and provide-persons > > * updated section on defining the XCAP usage; was missing some > required sections from xcap, and in particular, the default namespace > when used with xcap. THis default is > urn:ietf:params:xml:ns:pres-rules. > > * aligned with XCAP on usage of the filename 'index' when there is a > single authorization document > > * added back component-id and sub-handling to schema; somehow these > got accidentally deleted many versions back, though they were in my > version of the schema edited with xml-spy, they somehow didnt get into > the document. How this happened is a complete mystery to me. > > * changed integral values of sub-handling to 0,10,20,30 instead of > 0,1,2,3, to allow for new values to be inserted inbetween downstream. > > * changed integral values of provide-user-input from 0,1,2,3 to > 0,10,20,30 for the same reason > > * changed and to and > , to sync up with the final conclusion on this in > the data model and rpid > > * clarified that the provide-note permission applies only to the > top-level notes in person, device and tuple, NOT the notes embedded > within attributes themselves (such as ). > > * fixed broken example that wasnt compiling > > * cleaned up some remnants of references to substitution groups in the > text; we eliminated those from the schema some time back > > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Arjun Roychowdhury ------=_Part_6922_21342339.1141922108944 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
The <sub-handling> part of this authorization I-D is very useful= for authorization of 'any state sharing' - not just presence. 
 
My question, therefore, is that should the common-policy draft include= , at the least, some of the <sub-handling> clauses in its schema defi= nition instead of leaving it open for others to extend ? Or, the presence-a= uthorization draft makes its scope more general by saying the draft applies= to a wide variety of state sharing, not limited to presence authorization.
 
Specifically, irrespective of what we choose to share, we need a mecha= nism to specify authorization. Allow, Block, Confirm are fundamental action= s. If I choose to implement common-policy, it leaves an open area for 'acti= on' - and the only other draft I found which realizes 'action' is 'presence= -authorization' which then says it is related to presence, whereas I feel t= his should apply to a wider scope.
This only leaves the option of creating a new extension (which is not = necessary), or using 'presence-authorization's <sub-handling> ' spec = which is again, primarily motivated for 'presence sharing' .
 
regds
arjun
 


 
On 3/9/06, J= onathan Rosenberg <jdrosen@cisc= o.com> wrote:
I've submitted an updated to the= presence-rules draft. Until it appears
in the archives, you can pick it= up at:

http://www.jdrosen.net/papers/draft-ietf-simple-presence-rul= es-05.txt

The main changes are to align with the latest common p= olicy and to fix
bugs. I did a really thorough comb through the draft, doing detailedcomparisons with rpid and common-policy to make sure everything was
ali= gned. This review did pop out some bugs. The full set of changes is
below.

One change I did NOT make, was to define a new MIME type for = presence
authorization documents. This had been suggested in some maildiscussions over the last month or so, without clear consensus. I
believe it is a mistake to try to define a new MIME type for presence
ru= les separate from that of common policy. The reason is that I envision
p= olicy documents that contain rules from pres-rules, but also from other
extensions to common policy. Indeed, consider geolocation. We have amechanism for representing geolocatio in presence (pidf-lo), so one canimagine a presence document that contains BOTH geo-location and all
kinds of RPID data, and one would want a SINGLE authorization document
t= hat provides rules covering both types of data. Its trivial to
incorpora= te the policies in draft-ietf-geopriv-policy-08.txt into a
pres-rules do= cument. But, if each of these defines its own MIME type, it
draws harder lines between them, and I think thats a mistake.

An= other reason I didnt make the change is, we have discussed this in the
p= ast. Pres-rules has effectively been done for a while, and I'm loathe
to change anything at this point unless its just broken. Changing MIME
t= ypes to a pres-rules specific one is not fixing a bug, and thus I think
= we should avoid these kinds of design changes.

I believe this docume= nt is quite ready for WGLC (I dont think its had
one?), and it makes sense to do that along with common policy which is<= br>going through its own WGLC now.



Here are the full set of = changes:


* fixed bug reported on the list, which had the wrong r= epitition
values for provide-devices and provide-persons

* updated section= on defining the XCAP usage; was missing some
required sections from xca= p, and in particular, the default namespace
when used with xcap. THis de= fault is
urn:ietf:params:xml:ns:pres-rules.

* aligned with XCAP on usage = of the filename 'index' when there is a
single authorization document
* added back component-id and sub-handling to schema; somehow these
got accidentally deleted many versions back, though they were in my
= version of the schema edited with xml-spy, they somehow didnt get into
t= he document. How this happened is a complete mystery to me.

* change= d integral values of sub-handling to 0,10,20,30 instead of
0,1,2,3, to allow for new values to be inserted inbetween downstream.
* changed integral values of provide-user-input from 0,1,2,3 to
0,= 10,20,30 for the same reason

* changed <device-id> and <pro= vide-device-id> to <deviceID> and
<provide-deviceID>, to sync up with the final conclusion on this = in
the data model and rpid

* clarified that the provide-note perm= ission applies only to the
top-level notes in person, device and tuple, = NOT the notes embedded
within attributes themselves (such as <activities>).

* fix= ed broken example that wasnt compiling

* cleaned up some remnants of= references to substitution groups in the
text; we eliminated those from= the schema some time back


Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.&nb= sp;            =       600 Lanidex Plaza
Cisco Fellow  = ;            &n= bsp;            = ;        Parsippany, NJ 07054-2711
Ci= sco Systems
jdrosen@cisco.com         =             &nb= sp;        FAX:   (973) 9= 52-5050
http://www.jdrosen.net&nb= sp;            =             PHONE: (= 973) 952-5000
http://www.cisco.com

_______________________________________________
Simple maili= ng list
Simple@ietf.org
https://www1.ietf.org/m= ailman/listinfo/simple



--
Arjun Roychowdh= ury
------=_Part_6922_21342339.1141922108944-- --===============1698437503== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1698437503==-- From simple-bounces@ietf.org Thu Mar 09 16:19:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHSPf-0006U1-AO; Thu, 09 Mar 2006 16:11:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHSOn-0003xC-Vo; Thu, 09 Mar 2006 16:10:18 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHSOn-0002Qu-M5; Thu, 09 Mar 2006 16:10:17 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k29Ko20e020930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHS5C-00008L-Nl; Thu, 09 Mar 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 09 Mar 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-diff-03.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: , Errors-To: simple-bounces@ietf.org --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 : An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-diff-03.txt Pages : 14 Date : 2006-3-9 This specification defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). This format indicates the document that has changed and its former and new entity tags. It also can indicate the specific change that was made in the document, using an XML patch format. XCAP diff documents can be delivered to clients using a number of means, including a Session Initiation Protocol (SIP) event package. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-03.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-xcap-diff-03.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-xcap-diff-03.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: <2006-3-9133050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-diff-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-diff-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-9133050.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Thu Mar 09 16:43:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHSur-0004eL-1Q; Thu, 09 Mar 2006 16:43:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHS6f-0003TO-9i; Thu, 09 Mar 2006 15:51:33 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHS6e-0007Xa-I8; Thu, 09 Mar 2006 15:51:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k29Ko2vP024971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHS5C-00008B-MP; Thu, 09 Mar 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 09 Mar 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-05.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: , Errors-To: simple-bounces@ietf.org --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 : Presence Authorization Rules Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-rules-05.txt Pages : 27 Date : 2006-3-9 Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-05.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-rules-05.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-rules-05.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: <2006-3-9132858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-rules-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-rules-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-9132858.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Fri Mar 10 01:14:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHatV-0001VK-Ie; Fri, 10 Mar 2006 01:14:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHatU-0001VF-DT for simple@ietf.org; Fri, 10 Mar 2006 01:14:32 -0500 Received: from wproxy.gmail.com ([64.233.184.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHatQ-0001qF-5B for simple@ietf.org; Fri, 10 Mar 2006 01:14:32 -0500 Received: by wproxy.gmail.com with SMTP id i3so804608wra for ; Thu, 09 Mar 2006 22:14:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=NK1D7ukE42E3M007c+6AULjWfeHGxHOwyHWvPREXarFzVtCsmF6IQOUQDcuEzs1oIo2phgpV/yLUBBCnsy0qWQh81dwENgcvb9SxUgLo1Kugr0v3sRkp/VanyydkKNOFDzj1D0M+GttHt/l8RIGeUZqC4soxxx2yLjHY9zp7GrM= Received: by 10.64.210.10 with SMTP id i10mr443327qbg; Thu, 09 Mar 2006 22:14:27 -0800 (PST) Received: by 10.64.156.20 with HTTP; Thu, 9 Mar 2006 22:14:27 -0800 (PST) Message-ID: <7f5ac7240603092214r7d7d9a0mdccb823bc4cbd06a@mail.gmail.com> Date: Fri, 10 Mar 2006 15:14:27 +0900 From: "Mahesh Govind" To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Simple] presence redirection 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="===============0937434706==" Errors-To: simple-bounces@ietf.org --===============0937434706== Content-Type: multipart/alternative; boundary="----=_Part_14008_10961931.1141971267695" ------=_Part_14008_10961931.1141971267695 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I have a doubt about presence redirection .Please consider the following scenario A subscriber is having multiple AORs . One is his private id and other on= e is his office id . He dont want to give his private id to his clients at his office.But for some scenarios , he want to redirect his im messages to his home, with out revealing his private id to his clients . Currently is there any mechanism to do this , Please note that the servers for his both AORs may or may not be same .Also At home and at office he may be using different types of IM client software. I have a doubt whether the current mechanisms can handle this . Could you Please calrify . With thanks and regards Mahesh ------=_Part_14008_10961931.1141971267695 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi,
I have a doubt about presence redirection .Please consider the followi= ng scenario
 
A subscriber is having multiple  AORs  . One is his private = id and other one is his office id .
He dont want to  give his private id to his clients at his office= .But for some scenarios , he want to
redirect his   im messages to his home, with out revealing h= is  private id to his  clients .
Currently is there any mechanism to do this ,
Please note that the servers for his both AORs may or may not be same = .Also
At home and at office he may be using  different types of  I= M client software.
 
I have  a doubt whether the current mechanisms can handle this .<= /div>
 
Could you Please calrify .
 
With thanks and regards
Mahesh
 
 
------=_Part_14008_10961931.1141971267695-- --===============0937434706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0937434706==-- From simple-bounces@ietf.org Fri Mar 10 03:10:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHcht-0007Cf-AW; Fri, 10 Mar 2006 03:10:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHchs-0007BK-2t for simple@ietf.org; Fri, 10 Mar 2006 03:10:40 -0500 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHchn-0005Up-Gz for simple@ietf.org; Fri, 10 Mar 2006 03:10:37 -0500 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] Filtering: possible security issue? Date: Fri, 10 Mar 2006 09:09:54 +0100 Message-ID: <31721CD4D0090B4BA32CBA5E2C40AE9001E7483A@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Filtering: possible security issue? Thread-Index: AcZCt+XGGhW3twOwSPiufhjKZ8wAoABYblVA From: To: X-OriginalArrivalTime: 10 Mar 2006 08:10:34.0374 (UTC) FILETIME=[1B414A60:01C6441A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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: , Errors-To: simple-bounces@ietf.org I think, if this is the interpretation, the text needs to be rewrited more clearly since it could originate misunderstanding. BR, Michal Burda > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Wednesday, March 08, 2006 2:55 PM > To: Burda Michal > Cc: simple@ietf.org > Subject: Re: [Simple] Filtering: possible security issue? >=20 > Ignoring the filter in this sense does not mean not applying it. it > means that you replace the information that the filter is asking for in > a element with bogus information. For elements, this > doesnt apply i dont think. >=20 > Hisham >=20 > On Mar 8, 2006, at 2:29 PM, wrote: >=20 > > Hi, > > > > draft-ietf-simple-event-filter-funct-05.txt says: "If polite blocking > > is > > used by the notifier, the notifier may choose to ignore the filter, by > > choosing to deliver notifications containing bogus information in the > > unauthorised elements or attributes." > > > > I think it can result in a security leak since the subscriber could > > create such filter, that if ignored, gives the subscriber information > > that he/she is polite blocked... > > > > Could anyone please post any suggestions/comments? > > > > > > Best regards, > > > > > > Michal Burda > > > > > > _______________________________________________ > > 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 Mar 10 03:56:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHdPn-0002pC-Ci; Fri, 10 Mar 2006 03:56:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHdPm-0002p7-2K for simple@ietf.org; Fri, 10 Mar 2006 03:56:02 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHdPk-0007ET-Jy for simple@ietf.org; Fri, 10 Mar 2006 03:56:02 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2A8sGxU025789; Fri, 10 Mar 2006 10:54:18 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 10:55:57 +0200 Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Mar 2006 10:55:56 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2A8tt709336; Fri, 10 Mar 2006 10:55:55 +0200 (EET) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by kusti.research.nokia.com (Postfix) with ESMTP id 639C593B75; Fri, 10 Mar 2006 10:55:55 +0200 (EET) Subject: Re: [Simple] Issue with comparisons for triggerring From: Jari Urpalainen To: ext Sean Leahy In-Reply-To: References: Content-Type: text/plain Date: Fri, 10 Mar 2006 10:55:55 +0200 Message-Id: <1141980955.11852.20.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2006 08:55:56.0984 (UTC) FILETIME=[720E9B80:01C64420] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: simple-bounces@ietf.org Hisham and Sean! For me the current text is eligible enough although there are some implicit rules to interpret (and I think I'll understand the intention, but correct me if my example is wrong ...). If this really needs to be clarified (which may not be likely given the 48hours state), an example would be worth a xxx of words: Given the state can have values A, B or C and a transition from A to C is the trigger rule: state | action --------------- A | notify (initial subscription) B | - C | notify B | - C | - A | - C | notify --------------- Similar tables could be given with numbers with . But as I said I'm contented with the current text although in general I'll prefer good examples over text (lazy implementer ;-)). br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 10 04:14:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHddH-0000dw-S8; Fri, 10 Mar 2006 04:09:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHddG-0000dV-HQ for simple@ietf.org; Fri, 10 Mar 2006 04:09:58 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHddF-0007sn-2u for simple@ietf.org; Fri, 10 Mar 2006 04:09:58 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2A99svi011161 for ; Fri, 10 Mar 2006 11:09:56 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 11:09:55 +0200 Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Mar 2006 11:09:54 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2A99r711575 for ; Fri, 10 Mar 2006 11:09:53 +0200 (EET) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by kusti.research.nokia.com (Postfix) with ESMTP id AA23E93B75 for ; Fri, 10 Mar 2006 11:09:53 +0200 (EET) Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-partial-pidf-format-06.txt From: Jari Urpalainen To: simple@ietf.org In-Reply-To: References: Content-Type: text/plain Date: Fri, 10 Mar 2006 11:09:53 +0200 Message-Id: <1141981793.11852.30.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2006 09:09:54.0810 (UTC) FILETIME=[6570B5A0:01C64422] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: , Errors-To: simple-bounces@ietf.org On Wed, 2006-03-08 at 15:50 -0500, ext simple-bounces@ietf.org wrote: > 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 : Presence Information Data format (PIDF) Extension for Partial Presence > Author(s) : M. Lonnfors, et al. > Filename : draft-ietf-simple-partial-pidf-format-06.txt > Pages : 17 > Date : 2006-3-8 > > The Presence Information Document Format (PIDF) specifies the > baseline XML based format for describing presence information. One > of the characteristic of the PIDF is that the document always needs > to carry all presence information available for the presentity. In > some environments where low bandwidth and high latency links can > exist it is often beneficial to limit the amount of transported > information over the network. This document introduces a new MIME > type which enables transporting of either only the changed parts or > the full PIDF based presence information. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-06.txt > The changelog: * added "Internationalization Considerations" section (due to IESG comments on data-model, rpid etc.), i.e. usage of UTF-16 also possible, although UTF-8 is the RECOMMENDED UCS encoding * version attribute is optional * added rfc3265 reference * schemaLocation reference changed to registered IANA URN Otherwise this I-D is considered to be WGLC ready. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 10 04:18:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHdl2-00029q-RQ; Fri, 10 Mar 2006 04:18:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHdl0-00026f-Sy for simple@ietf.org; Fri, 10 Mar 2006 04:17:58 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHdkz-0008Bv-E0 for simple@ietf.org; Fri, 10 Mar 2006 04:17:58 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2A9HrYK025019 for ; Fri, 10 Mar 2006 11:17:56 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 11:17:54 +0200 Received: from mgw-int1.ntc.nokia.com ([172.21.143.96]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Mar 2006 11:17:53 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2A9Hr125811 for ; Fri, 10 Mar 2006 11:17:53 +0200 (EET) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by kusti.research.nokia.com (Postfix) with ESMTP id 0B91093B75 for ; Fri, 10 Mar 2006 11:17:53 +0200 (EET) Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-xml-patch-ops-02.txt From: Jari Urpalainen To: simple@ietf.org In-Reply-To: References: Content-Type: text/plain Date: Fri, 10 Mar 2006 11:17:52 +0200 Message-Id: <1141982272.11852.39.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2006 09:17:53.0629 (UTC) FILETIME=[82D6B0D0:01C64423] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: , Errors-To: simple-bounces@ietf.org On Wed, 2006-03-08 at 15:50 -0500, ext simple-bounces@ietf.org wrote: > 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 : An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors > Author(s) : J. Urpalainen > Filename : draft-ietf-simple-xml-patch-ops-02.txt > Pages : 22 > Date : 2006-3-8 > > Extensible Markup Language (XML) documents are widely used as > containers for the exchange and storage of arbitrary data in today's > systems. Updates to this data require transporting of the entire XML > document between hosts, unless there's a mechanism that allows > exchanging only the updates of XML documents. This document > describes an XML patch framework utilizing XML Path language (XPath) > selectors. These selector values and updated new data content > constitute the basis of patch operations described in this document. > In addition to them, with basic , and > directives a set of patches can then be applied to update an existing > XML document. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-xml-patch-ops-02.txt > The change log is minimal since the 01 version: * clarified error handling * some implementation warning when manipulating xml nodes This I-D is also considered to be WGLC ready. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 10 04:24:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHdr5-00047y-7c; Fri, 10 Mar 2006 04:24:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHdr3-00047t-Lp for simple@ietf.org; Fri, 10 Mar 2006 04:24:13 -0500 Received: from ousrvr.oulu.fi ([130.231.240.1] helo=oulu.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHdr2-0008Ow-5b for simple@ietf.org; Fri, 10 Mar 2006 04:24:13 -0500 Received: from paju.oulu.fi (paju.oulu.fi [130.231.240.20]) by oulu.fi (8.13.1/8.13.1) with ESMTP id k2A9OAwD010940 for ; Fri, 10 Mar 2006 11:24:10 +0200 (EET) Received: from [130.231.50.167] (s-inf-pc37.oulu.fi [130.231.50.167]) by paju.oulu.fi (8.12.10/8.12.10) with ESMTP id k2A9O93d022545; Fri, 10 Mar 2006 11:24:10 +0200 (EET) Message-ID: <441145B4.3050104@ee.oulu.fi> Date: Fri, 10 Mar 2006 11:24:04 +0200 From: Erkki Harjula User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Subject: [Simple] PIDFConn draft updated Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: , Errors-To: simple-bounces@ietf.org Hi everyone, We have submitted an updated version of the draft "PIDFConn: Extension to the Presence Information Data Format (PIDF) for Expressing Connectivity Features", draft-ala-kurikka-simple-pidfconn-01. The direct link to the document: http://www.ietf.org/internet-drafts/draft-ala-kurikka-simple-pidfconn-01.txt The changes were made based on the feedback we got in the Vancouver meeting, mainly focusing on the additional "range" attribute in the element. There are now also use cases as concrete examples of PIDFConn usage. We look forward to any comments, corrections, complaints or additions, especially concerning the newly introduced attribute. -Erkki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 10 04:39:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHe5T-0000eN-H8; Fri, 10 Mar 2006 04:39:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHe5R-0000e9-Az for simple@ietf.org; Fri, 10 Mar 2006 04:39:05 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHe5P-0000Gi-Tx for simple@ietf.org; Fri, 10 Mar 2006 04:39:05 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2A9d1hv020558 for ; Fri, 10 Mar 2006 11:39:03 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 11:39:01 +0200 Received: from [172.21.35.234] ([172.21.35.234]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Mar 2006 11:39:01 +0200 Message-ID: <44114935.9020406@nokia.com> Date: Fri, 10 Mar 2006 11:39:01 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "simple@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2006 09:39:01.0726 (UTC) FILETIME=[76AEEFE0:01C64426] X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Simple] Partial-publish update 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: , Errors-To: simple-bounces@ietf.org Hi, The partial publish draft [1] was updated, with these edits: - We removed versioning using the 'version' parameter, since it was overlapping with the normal etags-based versioning of partial publication state. Also, added some text explaining why this was done. - Added description of creating a modifying publication that contains full-state. This was previously omitted, although the text talked about when to issue such a publication. Other than that, there are no known issues left with the draft, and along with patch-ops, partial-pidf-format, and partial-notify, I think this is ready for WGLC. Cheers, Aki [1] http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-publish-04.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 10 06:51:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHg9h-0005Ld-Kd; Fri, 10 Mar 2006 06:51:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHg9g-0005LY-AB for simple@ietf.org; Fri, 10 Mar 2006 06:51:36 -0500 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHg9f-0003cJ-1P for simple@ietf.org; Fri, 10 Mar 2006 06:51:36 -0500 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 Date: Fri, 10 Mar 2006 12:50:24 +0100 Message-ID: <3ACC9A25264A684F82C71840111F97980138B9EB@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Filtering: triggering functionality - filters for one-time use? Thread-Index: AcZEONFHIxh0cJa2Q6abM7EQgh3IjQ== From: To: X-OriginalArrivalTime: 10 Mar 2006 11:51:20.0937 (UTC) FILETIME=[F2D26590:01C64438] X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Simple] Filtering: triggering functionality - filters for one-time use? 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: , Errors-To: simple-bounces@ietf.org Hi, I just want to make sure that I understand it correctly. Because triggers are being evaluated according to last notification sent to the watcher, then triggers like will result in only one notification, because the trigger cannot be fired again. If there is only trigger, then it = will be fired every time when the element changes to "open", even if the change compared to the previously sent document is not a change really ("open" to "open"). Correct? Thank you, Silvestr Peknik Software Specialist TietoEnator _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 10 07:53:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHh7D-0003dK-6e; Fri, 10 Mar 2006 07:53:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHh7C-0003cp-2J for simple@ietf.org; Fri, 10 Mar 2006 07:53:06 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHh77-0005RX-C0 for simple@ietf.org; Fri, 10 Mar 2006 07:53:06 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id CA32D194480 for ; Fri, 10 Mar 2006 13:52:59 +0100 (CET) Received: from [192.168.1.119] ([192.168.1.119]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 13:51:24 +0100 In-Reply-To: <3ACC9A25264A684F82C71840111F97980138B9EB@carrera.eu.tieto.com> References: <3ACC9A25264A684F82C71840111F97980138B9EB@carrera.eu.tieto.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5b4b3a9b0c3b4efbeaf77456c8ff5f49@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Filtering: triggering functionality - filters for one-time use? Date: Fri, 10 Mar 2006 13:53:26 +0100 To: X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 10 Mar 2006 12:51:24.0882 (UTC) FILETIME=[56F0C320:01C64441] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: , Errors-To: simple-bounces@ietf.org On Mar 10, 2006, at 12:50 PM, wrote: > Hi, I just want to make sure that I understand it correctly. > > Because triggers are being evaluated according to last notification > sent > to the watcher, then triggers like > will result in only one notification, because the trigger cannot be > fired again. If there is only trigger, then it will > be fired every time when the element changes to "open", even if the > change compared to the previously sent document is not a change really > ("open" to "open"). > > Correct? No, not correct. Change from open to open is not a change. means change from anything other than open to open. You can, however, have 2 triggers as follows: Hisham > > Thank you, > > Silvestr Peknik > Software Specialist > TietoEnator > > _______________________________________________ > 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 Mar 10 08:15:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHhSs-0005Vv-2A; Fri, 10 Mar 2006 08:15:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHhSr-0005UG-8k for simple@ietf.org; Fri, 10 Mar 2006 08:15:29 -0500 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHhSq-00062W-NV for simple@ietf.org; Fri, 10 Mar 2006 08:15:29 -0500 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 Date: Fri, 10 Mar 2006 14:15:26 +0100 Message-ID: <31721CD4D0090B4BA32CBA5E2C40AE9001E74BF0@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Filtering & Throttling paradox Thread-Index: AcZERLIQL+hIzC/7RK+lWmD7UzmPuQ== From: To: X-OriginalArrivalTime: 10 Mar 2006 13:15:28.0101 (UTC) FILETIME=[B32A8150:01C64444] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Simple] Filtering & Throttling paradox 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: , Errors-To: simple-bounces@ietf.org Accordingly to draft-niemi-sipping-event-throttle-03, throttling is the last component that processes the outgoing notifications. Thus, event notification filtering is executed before throttling. (See also e.g. OMA-TS-Presence_SIMPLE-V1_0-20051122-C.) Now consider this situation: 1. The user subscribes to someone's presence document. The subscriber sends some filter with triggers in the SUBSCRIBE message body. Initial notification (N1) is sent, as always. 2. The presence document changes, so new notification (N2) is prepared. Triggers are evaluated against N1 and N2. Suppose the triggers are passed and N2 has to be sent to the subscriber. However, before the notification N2 is really sent to the subscriber, it is held for a while in the throttling component. 3. A new presence document change appears, so next notification (N3) is prepared. Now suppose that N3 is such notification that causes the triggers' evaluation: - to pass, if evaluating triggers against N2 and N3, and - not to pass, if evaluating triggers against N1 and N3. If we decide N3 to be sent because the triggers' evaluation against N2 and N3 tells us so, N3 arrives to the throttling component and causes N2 to be discarded and not-delivered to the subscriber. Thus, it was wrong in the triggers' evaluation to compute them against N2 and N3 since N2 was not the really last notification sent to the subscriber. The last notification sent was obviously N1. In the other hand, if we decide N3 not to be sent because the triggers' evaluation against N1 and N3 tells us so, we are wrong too because in that case N2 is sent after a short time from the throttling component, thus N1 was not the very last notification sent, as N2 was. Both cases lead into a contradiction. So, it is impossible to have working throttling and event notification filtering together in a way as defined in draft-niemi-sipping-event-throttle-03 and draft-ietf-simple-filter-format-05. Concrete example: 1. Alice's presence document: happy 2. Bob subscribes with filter containing these triggers (ORed): T1 - changed from 'happy' to 'tired', T2 - changed from 'tired' to 'angry' 3. Alice's presence document changes to: tired 4. The notification to Bob has to be sent, however it is caught by the throttling component. 5. Alice's presence document changes again to: angry 6. Do we have to send the notification to Bob? I think, the answer to the question given in paragraph 6 is 'yes' since we have to deliver the user the most recent information. However, the example shows the complexity of the proposed filtering behaviour. It rises up the question of rationality of such proposal and it increases the importance of the following questions: - What are the benefits of such approach, that the triggering is computed against the "last previously sent notification"? What is the motivation of such approach? - Why not to change it to the "last change in presentity's presence information"? Such modification would solve many many issues - there will be no need to store any additional information per each subscription, such paradoxes as discussed above would not appear while the most usual use-cases would be covered as well... BR, Michal Burda _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 10 08:26:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHhdL-0005qQ-N5; Fri, 10 Mar 2006 08:26:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHhdL-0005qL-1c for simple@ietf.org; Fri, 10 Mar 2006 08:26:19 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHhdJ-0006Pn-It for simple@ietf.org; Fri, 10 Mar 2006 08:26:19 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2ADOWUH013822 for ; Fri, 10 Mar 2006 15:24:35 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 15:25:48 +0200 Received: from mgw-int1.ntc.nokia.com ([172.21.143.96]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Mar 2006 15:25:48 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2ADPl117978 for ; Fri, 10 Mar 2006 15:25:47 +0200 (EET) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by kusti.research.nokia.com (Postfix) with ESMTP id 558AE93B75 for ; Fri, 10 Mar 2006 15:25:47 +0200 (EET) From: Jari Urpalainen To: simple@ietf.org Content-Type: text/plain Date: Fri, 10 Mar 2006 15:25:47 +0200 Message-Id: <1141997147.11852.93.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2006 13:25:48.0355 (UTC) FILETIME=[24DDC130:01C64446] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Simple] nits of xcap-diff-03 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: , Errors-To: simple-bounces@ietf.org Hi! Overall the i-d looks good except the open issue, so some minor nits: -as IANA registers schema uris, I'd propose to use "urn:ietf:params:xml:schema:xml-patch-ops" urn as a schemaLocation value in . (partial-pidf-format uses this as well and it works with local files equally well). -extension of with is done without processContents="lax". I'd prefer to use it as "Any unknown elements MUST be ignored" aligns with it better imo. Of course the "signaling" of these extensions is difficult. -"Usage with an Event Package": "the client SHOULD perform a conditional GET for each document." I'll assume this conditional == If-Match: "foobar" in this case, not If-None-Match which is my typical interpretation of a conditional GET. So it should be clarified. Also "escape coded" -> "percent-encoded" doc-selector. That said, a really proper initial synchronisation is difficult with these two protocols (when those rapidly changing docs exist). Perhaps a slightly better implementation would cache all notifies before it has done all GETs but it is still far from perfect as it may not work because the server is not mandated to send all patches atomically. So either versioning with ETags (as noted in this i-d, i.e. like instance manipulation with http in rfc3229...) or multipart mime would work, both of which are a bit heavy and/or complex for the task... br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 10 08:32:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHhji-00009y-SD; Fri, 10 Mar 2006 08:32:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHhji-00009t-5v for simple@ietf.org; Fri, 10 Mar 2006 08:32:54 -0500 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHhjg-0006aW-O6 for simple@ietf.org; Fri, 10 Mar 2006 08:32:54 -0500 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] Issue with comparisons for triggerring Date: Fri, 10 Mar 2006 14:26:12 +0100 Message-ID: <31721CD4D0090B4BA32CBA5E2C40AE9001E74C10@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Issue with comparisons for triggerring Thread-Index: AcZCx1fAZWJPFjPpTS2BnyYNbuns8gBfmGDA From: To: X-OriginalArrivalTime: 10 Mar 2006 13:26:24.0816 (UTC) FILETIME=[3A994300:01C64446] X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: simple-bounces@ietf.org Jari wrote: > Looks like you are proposing 6 ;-). If I were to implement this (which > is btw. quite challenging), I would probably maintain only one document, > and the "trigger state" per watcher could be kept e.g. within the > watchers filter rule document, i.e. it could be e.g. an additional > attribute value within the element. But this is of course an > implementation issue. So imo keeping this "state information" does not > mean that you have to maintain the full published information. > Definitely this is additional state information to remember but I doubt > that it is not a major issue considering all the other tasks that you > have to implement. Another story is whether the text needs clarification > or not. In my opinion, it does not last to store the "trigger state" only. If the filtering would be implemented as proposed, I am convinced we need to store the whole "old" notifications because of partial publications creation. BR, Michal Burda _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 10 09:29:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHicN-0002gw-4C; Fri, 10 Mar 2006 09:29:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHicL-0002gr-LY for simple@ietf.org; Fri, 10 Mar 2006 09:29:21 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHicL-00009M-7x for simple@ietf.org; Fri, 10 Mar 2006 09:29:21 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2AESCVN017377 for ; Fri, 10 Mar 2006 16:28:16 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 16:29:18 +0200 Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Mar 2006 16:29:18 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2AETD712895 for ; Fri, 10 Mar 2006 16:29:13 +0200 (EET) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by kusti.research.nokia.com (Postfix) with ESMTP id 953DE93B75 for ; Fri, 10 Mar 2006 16:29:13 +0200 (EET) Subject: RE: [Simple] Issue with comparisons for triggerring From: Jari Urpalainen To: simple@ietf.org In-Reply-To: <31721CD4D0090B4BA32CBA5E2C40AE9001E74C10@carrera.eu.tieto.com> References: <31721CD4D0090B4BA32CBA5E2C40AE9001E74C10@carrera.eu.tieto.com> Content-Type: text/plain Date: Fri, 10 Mar 2006 16:29:13 +0200 Message-Id: <1142000953.11852.122.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2006 14:29:18.0708 (UTC) FILETIME=[04037B40:01C6444F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Errors-To: simple-bounces@ietf.org On Fri, 2006-03-10 at 14:26 +0100, ext simple-bounces@ietf.org wrote: > Jari wrote: > > Looks like you are proposing 6 ;-). If I were to implement this (which > > is btw. quite challenging), I would probably maintain only one > document, > > and the "trigger state" per watcher could be kept e.g. within the > > watchers filter rule document, i.e. it could be e.g. an additional > > attribute value within the element. But this is of course an > > implementation issue. So imo keeping this "state information" does not > > mean that you have to maintain the full published information. > > Definitely this is additional state information to remember but I > doubt > > that it is not a major issue considering all the other tasks that you > > have to implement. Another story is whether the text needs > clarification > > or not. > > > In my opinion, it does not last to store the "trigger state" only. If > the filtering would be implemented as proposed, I am convinced we need > to store the whole "old" notifications because of partial publications > creation. > > BR, > > Michal Burda > You mean partial notifications ? Combination of these two is certainly another story as they are two separate issues. Partial notification only patches the last event state which must be stored somehow, of course per subscriber and e.g. auto diffing is applied after filtering. I would probably store this last state (==1 doc/subscriber) because it seems the most trivial. The thread however, is about how triggering works with filtering. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 10 09:56:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHj2w-00026B-0H; Fri, 10 Mar 2006 09:56:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHj2v-0001zS-7U for simple@ietf.org; Fri, 10 Mar 2006 09:56:49 -0500 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHj2t-0000ga-Q5 for simple@ietf.org; Fri, 10 Mar 2006 09:56:49 -0500 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] Filtering: triggering functionality - filters for one-time use? Date: Fri, 10 Mar 2006 15:56:26 +0100 Message-ID: <3ACC9A25264A684F82C71840111F9798013D4496@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Filtering: triggering functionality - filters for one-time use? Thread-Index: AcZEQb0dkWjRNzEXQp2UN6wVKTCB5AAD4nWQ From: To: X-OriginalArrivalTime: 10 Mar 2006 14:56:46.0164 (UTC) FILETIME=[D9F95140:01C64452] X-Spam-Score: 0.2 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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: , Errors-To: simple-bounces@ietf.org So it is intended that filter with trigger is one-time trigger which will result in only one notification and no more? This makes it impossible to be notified about change to certain state only; you must always define that you want to be notified about change from the state, or you will receive one notification only. Silvestr > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Friday, March 10, 2006 1:53 PM > To: Peknik Silvestr > Cc: simple@ietf.org > Subject: Re: [Simple] Filtering: triggering functionality - filters for > one-time use? >=20 >=20 > On Mar 10, 2006, at 12:50 PM, wrote: >=20 > > Hi, I just want to make sure that I understand it correctly. > > > > Because triggers are being evaluated according to last notification > > sent > > to the watcher, then triggers like > > will result in only one notification, because the trigger cannot be > > fired again. If there is only trigger, then it will > > be fired every time when the element changes to "open", even if the > > change compared to the previously sent document is not a change really > > ("open" to "open"). > > > > Correct? >=20 > No, not correct. Change from open to open is not a change. to=3D"open"> means change from anything other than open to open. >=20 > You can, however, have 2 triggers as follows: >=20 > > >=20 > Hisham >=20 > > > > Thank you, > > > > Silvestr Peknik > > Software Specialist > > TietoEnator > > > > _______________________________________________ > > 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 Mar 10 09:58:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHj4f-0007ZX-Ns; Fri, 10 Mar 2006 09:58:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHj4d-0007Yq-Ku for simple@ietf.org; Fri, 10 Mar 2006 09:58:35 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHj4d-0000k5-16 for simple@ietf.org; Fri, 10 Mar 2006 09:58:35 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 6DA08194486 for ; Fri, 10 Mar 2006 15:58:33 +0100 (CET) Received: from [192.168.1.119] ([192.168.1.119]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 15:56:58 +0100 In-Reply-To: <3ACC9A25264A684F82C71840111F9798013D4496@carrera.eu.tieto.com> References: <3ACC9A25264A684F82C71840111F9798013D4496@carrera.eu.tieto.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <97764d4361323e00a008aeb1d883692e@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Filtering: triggering functionality - filters for one-time use? Date: Fri, 10 Mar 2006 15:58:59 +0100 To: X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 10 Mar 2006 14:56:58.0346 (UTC) FILETIME=[E13C24A0:01C64452] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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: , Errors-To: simple-bounces@ietf.org You can have without the "from" and "to" attributes. Is that what you are looking for? Hisham On Mar 10, 2006, at 3:56 PM, wrote: > So it is intended that filter with trigger is > one-time trigger which will result in only one notification and no > more? > > This makes it impossible to be notified about change to certain state > only; you must always define that you want to be notified about change > from the state, or you will receive one notification only. > > Silvestr > >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Friday, March 10, 2006 1:53 PM >> To: Peknik Silvestr >> Cc: simple@ietf.org >> Subject: Re: [Simple] Filtering: triggering functionality - filters > for >> one-time use? >> >> >> On Mar 10, 2006, at 12:50 PM, wrote: >> >>> Hi, I just want to make sure that I understand it correctly. >>> >>> Because triggers are being evaluated according to last notification >>> sent >>> to the watcher, then triggers like >>> will result in only one notification, because the trigger cannot be >>> fired again. If there is only trigger, then it > will >>> be fired every time when the element changes to "open", even if the >>> change compared to the previously sent document is not a change > really >>> ("open" to "open"). >>> >>> Correct? >> >> No, not correct. Change from open to open is not a change. > to="open"> means change from anything other than open to open. >> >> You can, however, have 2 triggers as follows: >> >> >> >> >> Hisham >> >>> >>> Thank you, >>> >>> Silvestr Peknik >>> Software Specialist >>> TietoEnator >>> >>> _______________________________________________ >>> 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 Mar 10 11:30:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHkVo-0008VA-1t; Fri, 10 Mar 2006 11:30:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHkVl-0008QL-Pq for simple@ietf.org; Fri, 10 Mar 2006 11:30:41 -0500 Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHkVj-0004E6-Am for simple@ietf.org; Fri, 10 Mar 2006 11:30:41 -0500 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id k2AAeB8X023887; Fri, 10 Mar 2006 16:30:31 GMT (envelope-from Sean.Leahy@marconi.com) To: "Jari Urpalainen Subject: Re: [Simple] Issue with comparisons for triggerring MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Sean Leahy" Date: Fri, 10 Mar 2006 15:07:56 +0000 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 10/03/2006 16:29:49, Serialize complete at 10/03/2006 16:29:49 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 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: , Content-Type: multipart/mixed; boundary="===============1157390349==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============1157390349== Content-Type: multipart/alternative; boundary="=_alternative 00531FD88025712D_=" This is a multipart message in MIME format. --=_alternative 00531FD88025712D_= Content-Type: text/plain; charset="us-ascii" Looks good to me - although I still think we do not need the struck-through text - it only seems to confuse. "The element is used to identify the XML element or attribute, from the package specific XML document, whose value MUST change, compared to the "previous XML document", in order to activate the trigger and cause the content to be delivered. Previous XML document in this context refers to the last XML document that was selected for delivery delivered to that specific subscription before any filter was applied to it." Regards, Sean Jari Urpalainen 10/03/2006 08:55 To: ext Sean Leahy cc: "Hisham Khartabil . But as I said I'm contented with the current text although in general I'll prefer good examples over text (lazy implementer ;-)). br, Jari --=_alternative 00531FD88025712D_= Content-Type: text/html; charset="us-ascii"
Looks good to me - although I still think we do not need the struck-through text - it only seems to confuse.

"The <changed> element is used to identify the XML element or attribute, from the package specific XML document, whose value MUST change, compared to the "previous XML document", in order to activate the trigger and cause the content to be delivered.  Previous XML document in this context refers to the last XML document that was selected for delivery delivered to that specific subscription before any filter was applied to it."

Regards,
Sean



Jari Urpalainen <jari.urpalainen@nokia.com>

10/03/2006 08:55

       
        To:        ext Sean Leahy <Sean.Leahy@marconi.com>
        cc:        "Hisham Khartabil <hisham.khartabil", simple@ietf.org
        Subject:        Re: [Simple] Issue with comparisons for triggerring



Hisham and Sean!

For me the current text is eligible enough although there are some
implicit rules to interpret (and I think I'll understand the intention,
but correct me if my example is wrong ...). If this really needs to be
clarified (which may not be likely given the 48hours state), an example
would be worth a xxx of words:

Given the state can have values A, B or C and a transition from A to C
is the trigger rule:

state | action
---------------
A     | notify (initial subscription)
B     | -
C     | notify
B     | -
C     | -
A     | -
C     | notify
---------------

Similar tables could be given with numbers with <by>. But as I said I'm
contented with the current text although in general I'll prefer good
examples over text (lazy implementer ;-)).
br,
Jari

--=_alternative 00531FD88025712D_=-- --===============1157390349== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1157390349==-- From simple-bounces@ietf.org Fri Mar 10 11:59:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHkxe-0008FO-NR; Fri, 10 Mar 2006 11:59:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHkxc-0008F1-R0 for simple@ietf.org; Fri, 10 Mar 2006 11:59:28 -0500 Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHkxc-00059s-0t for simple@ietf.org; Fri, 10 Mar 2006 11:59:28 -0500 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id k2AGGAOf001842; Fri, 10 Mar 2006 16:59:20 GMT (envelope-from Sean.Leahy@marconi.com) To: " Subject: Re: [Simple] Filtering & Throttling paradox MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Sean Leahy" Date: Fri, 10 Mar 2006 14:16:00 +0000 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 10/03/2006 16:58:37, Serialize complete at 10/03/2006 16:58:37 X-Spam-Score: 0.5 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f 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: , Content-Type: multipart/mixed; boundary="===============1365075913==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============1365075913== Content-Type: multipart/alternative; boundary="=_alternative 004E5EC78025712D_=" This is a multipart message in MIME format. --=_alternative 004E5EC78025712D_= Content-Type: text/plain; charset="us-ascii" I am not an authority on this but your suggestion "last change in presentity's presence information" seems to confuse 'changed from to' with 'changed to'. I would suggest that If N2 is discarded and not-delivered, the record should show that it was not delivered or (more likely) that the last delivered value of the triggered element was as in N1. i.e. the record of what was last delivered should be able to take account of all blockages including throttling. The result would be: 1. Alice's presence document: happy 2. Bob subscribes with filter containing these triggers: T1 - changed from 'happy' to 'tired', T2 - changed from 'tired' to 'angry' 3. Alice's presence document changes to: tired 4. The notification to Bob has to be sent, however it is caught by the throttling component. 5. Alice's presence document changes again to: angry 6. N3 (angry) is sent to Bob only if N2 (tired) is sent to Bob. 7. If N2 (tired) is not sent, neither (angry nor tired) is sent. However, If Bob/Bob's client had anticipated this possibility, the filter could have been set to : T1 - changed from 'happy' to 'tired', T2 - changed from 'tired' to 'angry', T3 - changed from ''happy' to 'angry' or simply: T1 - changed to 'tired', T2 - changed to 'angry'. As long as the result is predictable from the requirements, there will always a responsibility on the client to subscribe appropriately. Regards, Sean 10/03/2006 13:15 To: cc: Subject: [Simple] Filtering & Throttling paradox Accordingly to draft-niemi-sipping-event-throttle-03, throttling is the last component that processes the outgoing notifications. Thus, event notification filtering is executed before throttling. (See also e.g. OMA-TS-Presence_SIMPLE-V1_0-20051122-C.) Now consider this situation: 1. The user subscribes to someone's presence document. The subscriber sends some filter with triggers in the SUBSCRIBE message body. Initial notification (N1) is sent, as always. 2. The presence document changes, so new notification (N2) is prepared. Triggers are evaluated against N1 and N2. Suppose the triggers are passed and N2 has to be sent to the subscriber. However, before the notification N2 is really sent to the subscriber, it is held for a while in the throttling component. 3. A new presence document change appears, so next notification (N3) is prepared. Now suppose that N3 is such notification that causes the triggers' evaluation: - to pass, if evaluating triggers against N2 and N3, and - not to pass, if evaluating triggers against N1 and N3. If we decide N3 to be sent because the triggers' evaluation against N2 and N3 tells us so, N3 arrives to the throttling component and causes N2 to be discarded and not-delivered to the subscriber. Thus, it was wrong in the triggers' evaluation to compute them against N2 and N3 since N2 was not the really last notification sent to the subscriber. The last notification sent was obviously N1. In the other hand, if we decide N3 not to be sent because the triggers' evaluation against N1 and N3 tells us so, we are wrong too because in that case N2 is sent after a short time from the throttling component, thus N1 was not the very last notification sent, as N2 was. Both cases lead into a contradiction. So, it is impossible to have working throttling and event notification filtering together in a way as defined in draft-niemi-sipping-event-throttle-03 and draft-ietf-simple-filter-format-05. Concrete example: 1. Alice's presence document: happy 2. Bob subscribes with filter containing these triggers (ORed): T1 - changed from 'happy' to 'tired', T2 - changed from 'tired' to 'angry' 3. Alice's presence document changes to: tired 4. The notification to Bob has to be sent, however it is caught by the throttling component. 5. Alice's presence document changes again to: angry 6. Do we have to send the notification to Bob? I think, the answer to the question given in paragraph 6 is 'yes' since we have to deliver the user the most recent information. However, the example shows the complexity of the proposed filtering behaviour. It rises up the question of rationality of such proposal and it increases the importance of the following questions: - What are the benefits of such approach, that the triggering is computed against the "last previously sent notification"? What is the motivation of such approach? - Why not to change it to the "last change in presentity's presence information"? Such modification would solve many many issues - there will be no need to store any additional information per each subscription, such paradoxes as discussed above would not appear while the most usual use-cases would be covered as well... BR, Michal Burda _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --=_alternative 004E5EC78025712D_= Content-Type: text/html; charset="us-ascii"
I am not an authority on this but your suggestion "last change in presentity's presence information" seems to confuse 'changed from to' with 'changed to'.

I would suggest that If N2 is discarded and not-delivered, the record should show that it was not delivered or (more likely) that the last delivered value of the triggered element was as in N1. i.e. the record of what was last delivered should be able to take account of all blockages including throttling.

The result would be:

1. Alice's presence document: <mood>happy</mood>
2. Bob subscribes with filter containing these triggers: T1 -
changed from 'happy' to 'tired', T2 - changed from 'tired' to 'angry'
3. Alice's presence document changes to: <mood>tired</mood>
4. The notification to Bob has to be sent, however it is caught by the
throttling component.
5. Alice's presence document changes again to: <mood>angry</mood>
6. N3 (angry) is sent to Bob only if N2 (tired) is sent to Bob.
7. If N2 (tired) is not sent, neither (angry nor tired) is sent.

However, If Bob/Bob's client had anticipated this possibility, the filter could have been set to :

T1 - changed from 'happy' to 'tired', T2 - changed from 'tired' to 'angry', T3 - changed from ''happy' to 'angry' <which is quite possible>

or simply:

 T1 - changed to 'tired', T2 - changed to 'angry'.

As long as the result is predictable from the requirements, there will always a responsibility on the client to subscribe appropriately.
Regards,
Sean



<Michal.Burda@tietoenator.com>

10/03/2006 13:15

       
        To:        <simple@ietf.org>
        cc:        
        Subject:        [Simple] Filtering & Throttling paradox



Accordingly to draft-niemi-sipping-event-throttle-03, throttling is the
last component that processes the outgoing notifications. Thus, event
notification filtering is executed before throttling. (See also e.g.
OMA-TS-Presence_SIMPLE-V1_0-20051122-C.)

Now consider this situation:

1. The user subscribes to someone's presence document. The subscriber
sends some filter with triggers in the SUBSCRIBE message body. Initial
notification (N1) is sent, as always.

2. The presence document changes, so new notification (N2) is prepared.
Triggers are evaluated against N1 and N2. Suppose the triggers are
passed and N2 has to be sent to the subscriber. However, before the
notification N2 is really sent to the subscriber, it is held for a while
in the throttling component.

3. A new presence document change appears, so next notification (N3) is
prepared. Now suppose that N3 is such notification that causes the
triggers' evaluation:
  - to pass, if evaluating triggers against N2 and N3, and
  - not to pass, if evaluating triggers against N1 and N3.

If we decide N3 to be sent because the triggers' evaluation against N2
and N3 tells us so, N3 arrives to the throttling component and causes N2
to be discarded and not-delivered to the subscriber. Thus, it was wrong
in the triggers' evaluation to compute them against N2 and N3 since N2
was not the really last notification sent to the subscriber. The last
notification sent was obviously N1.

In the other hand, if we decide N3 not to be sent because the triggers'
evaluation against N1 and N3 tells us so, we are wrong too because in
that case N2 is sent after a short time from the throttling component,
thus N1 was not the very last notification sent, as N2 was.

Both cases lead into a contradiction. So, it is impossible to have
working throttling and event notification filtering together in a way as
defined in draft-niemi-sipping-event-throttle-03 and
draft-ietf-simple-filter-format-05.

Concrete example:

1. Alice's presence document: <mood>happy</mood>
2. Bob subscribes with filter containing these triggers (ORed): T1 -
changed from 'happy' to 'tired', T2 - changed from 'tired' to 'angry'
3. Alice's presence document changes to: <mood>tired</mood>
4. The notification to Bob has to be sent, however it is caught by the
throttling component.
5. Alice's presence document changes again to: <mood>angry</mood>
6. Do we have to send the notification to Bob?

I think, the answer to the question given in paragraph 6 is 'yes' since
we have to deliver the user the most recent information. However, the
example shows the complexity of the proposed filtering behaviour. It
rises up the question of rationality of such proposal and it increases
the importance of the following questions:

- What are the benefits of such approach, that the triggering is
computed against the "last previously sent notification"? What is the
motivation of such approach?

- Why not to change it to the "last change in presentity's presence
information"? Such modification would solve many many issues - there
will be no need to store any additional information per each
subscription, such paradoxes as discussed above would not appear while
the most usual use-cases would be covered as well...

BR,

Michal Burda

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

--=_alternative 004E5EC78025712D_=-- --===============1365075913== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1365075913==-- From simple-bounces@ietf.org Sun Mar 12 22:50:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIe4N-0004ri-N6; Sun, 12 Mar 2006 22:50:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIe4M-0004rX-8P for simple@ietf.org; Sun, 12 Mar 2006 22:50:06 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIe4K-000647-Eg for simple@ietf.org; Sun, 12 Mar 2006 22:50:06 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IW100EH8SGXGD@szxga02-in.huawei.com> for simple@ietf.org; Mon, 13 Mar 2006 12:00:34 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IW1009MNSGUMF@szxga02-in.huawei.com> for simple@ietf.org; Mon, 13 Mar 2006 12:00:33 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IW100FSESMNE5@szxml01-in.huawei.com> for simple@ietf.org; Mon, 13 Mar 2006 12:04:02 +0800 (CST) Date: Mon, 13 Mar 2006 11:47:23 +0800 From: Xiao Wang To: simple@ietf.org Message-id: <017001c64650$d69e89c0$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZGUNZuTG9a+ucFSqCA82cPfxujcQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Simple] question of filter triger "OR" operation 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: , Errors-To: simple-bounces@ietf.org Hi, all In the draft-ietf-simple-filter-format-05, multiple elements in a element denotes the "OR" operation. I think if can add a function of "and" operation between elements, it is really useful. Xiao _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Mar 12 23:40:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIer8-00078z-Cc; Sun, 12 Mar 2006 23:40:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIer7-00078p-Fp for simple@ietf.org; Sun, 12 Mar 2006 23:40:29 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIeqr-0007RO-T8 for simple@ietf.org; Sun, 12 Mar 2006 23:40:29 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IW10004BUESTA@szxga01-in.huawei.com> for simple@ietf.org; Mon, 13 Mar 2006 12:42:28 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IW1007P8UES0H@szxga01-in.huawei.com> for simple@ietf.org; Mon, 13 Mar 2006 12:42:28 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IW100LKTUIEGD@szxml02-in.huawei.com> for simple@ietf.org; Mon, 13 Mar 2006 12:44:41 +0800 (CST) Date: Mon, 13 Mar 2006 12:31:41 +0800 From: Xiao Wang To: simple@ietf.org Message-id: <017101c64657$06ba4e90$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZGVwaYzLgE+2SDTpqq+kUjYr6Tqw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Simple] question of filter trigger for notifier's local policy 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: , Errors-To: simple-bounces@ietf.org Hi, all If subscriber subscribes presence information with filer triggers which trigger's elements are forbidden to subscribe by notifier's local policy , how to do it? If notifier returns failure response, subscriber how to known which elements are forbidden access and send a new SUBSCRIBE. If notifier omits the forbidden access trigger's elements, it will lead to a security hole, subscriber can use this to get forbidden access information. Xiao _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 13 06:28:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIlE6-0005ET-Pk; Mon, 13 Mar 2006 06:28:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIlE5-0005EO-G8 for simple@ietf.org; Mon, 13 Mar 2006 06:28:37 -0500 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIlE2-0002pe-UT for simple@ietf.org; Mon, 13 Mar 2006 06:28:37 -0500 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] Issue with comparisons for triggerring Date: Mon, 13 Mar 2006 12:28:29 +0100 Message-ID: <31721CD4D0090B4BA32CBA5E2C40AE9001EC016B@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Issue with comparisons for triggerring Thread-Index: AcZEIMUNuOOAFgxkRierpyVCb09x+wCVm0iQ From: To: X-OriginalArrivalTime: 13 Mar 2006 11:28:32.0890 (UTC) FILETIME=[42A43DA0:01C64691] X-Spam-Score: 0.2 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: jari.urpalainen@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: , Errors-To: simple-bounces@ietf.org > -----Original Message----- > From: Jari Urpalainen [mailto:jari.urpalainen@nokia.com] > Sent: Friday, March 10, 2006 9:56 AM > To: ext Sean Leahy > Cc: simple@ietf.org > Subject: Re: [Simple] Issue with comparisons for triggerring >=20 > Hisham and Sean! >=20 > For me the current text is eligible enough although there are some > implicit rules to interpret (and I think I'll understand the intention, > but correct me if my example is wrong ...). If this really needs to be > clarified (which may not be likely given the 48hours state), an example > would be worth a xxx of words: >=20 > Given the state can have values A, B or C and a transition from A to C > is the trigger rule: >=20 > state | action > --------------- > 1: A | notify (initial subscription) > 2: B | - > 3: C | notify > 4: B | - > 5: C | - > 6: A | - > 7: C | notify > --------------- I do not completely understand, why the third notification is sent to the subscriber. draft-ietf-simple-filter-format-05 says: "The element is used to identify the XML element or attribute, from the package specific XML document, whose value MUST change, compared to the "previous XML document", in order to activate the trigger and cause the content to be delivered. Previous XML document in this context refers to the last XML document that was selected for delivery to that specific subscription before any filter was applied to it." As far as I understand the above cited text, the trigger in step (7) has to be evaluated accordingly to the second notification (step 3), because it is the last XML document that was selected for delivery. Thus, if comparing states from step 3 and step 7, there is no difference (both are "C"), so the last notification shouldn't be sent. In fact, no notification would be sent ever unless someone changes the triggering criteria. Btw, it sounds very strange to me... >=20 > Similar tables could be given with numbers with . But as I said I'm > contented with the current text although in general I'll prefer good > examples over text (lazy implementer ;-)). > br, > Jari >=20 >=20 >=20 >=20 > _______________________________________________ > 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 Mar 14 00:50:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ2Q3-00085A-Rs; Tue, 14 Mar 2006 00:50:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ2Q2-00083P-No for simple@ietf.org; Tue, 14 Mar 2006 00:50:06 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ2Q2-0004uO-B9 for simple@ietf.org; Tue, 14 Mar 2006 00:50:06 -0500 X-IronPort-AV: i="4.02,189,1139202000"; d="scan'208"; a="29988506:sNHT46635000" X-MimeOLE: Produced By Microsoft Exchange V6.5 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] IMDN? Date: Tue, 14 Mar 2006 00:51:50 -0500 Message-ID: <330A23D8336C0346B5C1A5BB19666647026A2F7D@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] IMDN? Thread-Index: AcY+KWOX7TV2VcV7QGO5A6RWykImEQI4mOgA From: "Burger, Eric" To: "Laurent Steffan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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: , Errors-To: simple-bounces@ietf.org Long posts are good! It means someone is reading the draft!!! Disposition is a term of messaging art. I'd be hard pressed to change = it, but I too can be persuaded. Good point on the message ID. The SHOULD, with the clarifying text = (unless you can't) sounds good. Displayed works for me. A lot of the editorial stuff is excellent, and should make the draft = more understandable. Thanks.=20 -----Original Message----- From: Laurent Steffan [mailto:suivi_ietf@laurentsteffan.com]=20 Sent: Thursday, March 02, 2006 1:43 PM To: Simple WG Cc: Burger, Eric Subject: Re: [Simple] IMDN? Hi Eric, Here are some comments on your draft. 1/ On the term Delivery: 1.a) you have in some places changed "Delivery" to "Disposition", but not consistently : for instance on page 5 (in the "Introduction") you state "This notification message is the Instant Message Disposition Notification (IMDN)" while the title, and elsewhere, says "Delivery". 1.b) While I do believe that reading of a message by a user is different form the protocol action called delivery, I also find that "Disposition" is not a very good term. Does it refer to "disposing *of*" a message ? not really, since the message is only handed over to the user who may then read it, delete it, have it processed by an automatic system, or do whatever else she wants ("she" being on the receiver side...). So what does it refer to ? Also, the term Disposition of a message may be used (e.g. in some RFCs) to describe the layout of a message, so that's misleading. I'd rather call the process you describe by another term: "Acceptance", perhaps (IM User Acceptance Notification ??? er...) OTOH, RFC 3798 makes a precedent, so I won't enter a lost battle... 2/ On the globally unique identifier : You state "A UAC MUST include a globally unique Message-ID. It is necessary for the Message-ID to be unique to the UAC in order for the UAC to be able to exactly correlate IMDN's with the messages they refer = to". This is OK with me. However, part of your document describes conditions in which this uniqueness is not easily achievable, if at all : "Devices with limited resources and a high likelihood of total failure, such as a mobile phone, will lose their IMDN request state on total = failure" so I wonder what will happen to the uniqueness of the Message-ID when such a device is reset : what's to prevent the device from reusing Message-IDs that it has already used ? of course I can envision deriving the Message-ID from the contents of the message (a hash function for instance) but is this practical for a device with "limited resources" ? In order to take care of that difficulty, you may want to change your MUST to a SHOULD. (OTOH, you may want to tell me where my reasoning is faulty, I wouldn't be too surprised...) Also, I think you should specify how the *globally unique* Message-ID is built : does it consist of a "device-identifier" + "local message identifier", for instance ? or is it derived from the message itself (see above) ? or random within a large space ? ... 3/ In 6.2.2, "processed" : You state that "the target URI of the message is a B2BUA", but that's not necessarily the case since in 9.2, "Recipient is the End User UAS", you say that "the UAS SHOULD generate a processed IMDN" 4/ "There are three broad categories of disposition states", but you actually name four. ;-) Besides, this is the only place where you speak of categories: perhaps you could just say "states" which is after all what you call them later. 5/ When you say "The 'read' state is straightforward", it seems a bit odd to find that "one cannot determine a priori the user actually read the message". Perhaps "displayed" might better capture your meaning. oh, and on the same page (3rd line from the top) you still have a reference to "deleted" from your previous draft. I think you might replace it with "processed". 6/ In section 8, you mix actions of the Requesting UAC with those of the B2BUA. I think for clarity it would be better to cleanly separate the protocol into "Requesting UAC Behaviour", "B2BUA Behaviour" (split from the current section 8) and "Reporting UAC Actions" (which already exists as section 9). OK, I'll stop there, sorry for the long post! Best regards, Laurent On 19.02.2006 09:03, Burger, Eric wrote: > There have been exactly zero comments on > draft-burger-simple-imdn-03.txt. I know there are many open issues. >=20 > We were hoping to submit a work group draft -00. The deadline is > approaching. The open issues are still open. >=20 > Does anyone care about IMDN? If no one reads the drafts or comments = on > them, then the work is finished, in that the draft will expire and the > world will not have a standard mechanism for IM delivery reports. --=20 Laurent Steffan LAMSADE (Universit=E9 Paris Dauphine) _______________________________________________ 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 Mar 14 05:39:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ6wI-0001KI-2x; Tue, 14 Mar 2006 05:39:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ6wH-0001Ji-An for simple@ietf.org; Tue, 14 Mar 2006 05:39:41 -0500 Received: from tidos.tid.es ([193.145.240.2] helo=correo.tid.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ6wF-0004nt-UE for simple@ietf.org; Tue, 14 Mar 2006 05:39:41 -0500 Received: from matrix2 (matrix2.hi.inet [10.95.24.224]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IW400F4L5LZEQ@tid.hi.inet> for simple@ietf.org; Tue, 14 Mar 2006 11:39:35 +0100 (MET) Date: Tue, 14 Mar 2006 11:39:38 +0100 From: =?iso-8859-1?Q?Gustavo_Garc=EDa_Bernardo?= To: simple@ietf.org Message-id: <015901c64753$980c7a10$4345fea9@matrix2> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcZHU5fa4UtBMHhzT2yye+UOgmCxrQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Subject: [Simple] "offline" watcher info 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="===============0494214777==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0494214777== Content-type: multipart/alternative; boundary="Boundary_(ID_zrBaDIYcxkuPydWsD0dt3A)" This is a multi-part message in MIME format. --Boundary_(ID_zrBaDIYcxkuPydWsD0dt3A) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi, =20 For implementing a SIP Instant Messenger it is necessary that a user A = could detect when other user B is subscribing to his presence, so that A could authorize or deny it modifying his presence rules (according to draft-ietf-simple-presence-rules-04). =20 =20 I think this could be achieved with watcher info (RFC3857) if A is = online (and subscribed to his watcher info) at B subscription time, but How = should it works if A is offline at these moment? =20 =20 Thanks =20 Gustavo Garc=EDa =20 =20 =20 --Boundary_(ID_zrBaDIYcxkuPydWsD0dt3A) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable 
Hi,
 
For =
implementing a SIP Instant Messenger it is necessary that a user A could =
detect when other user B is subscribing to his presence, so that A could =
authorize or deny it modifying his presence rules (according to =
draft-ietf-simple-presence-rules-04).=A0 =

 
I think =
this could be achieved with watcher info (RFC3857) if A is online (and =
subscribed to his watcher info) at B subscription time, but How should =
it works if A is offline at these moment?=A0 =

 
Thanks
 
Gustavo =
Garc=EDa
 
 

 

--Boundary_(ID_zrBaDIYcxkuPydWsD0dt3A)-- --===============0494214777== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0494214777==-- From simple-bounces@ietf.org Tue Mar 14 21:15:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJLXk-0007ja-Qe; Tue, 14 Mar 2006 21:15:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJLXj-0007jV-Bk for simple@ietf.org; Tue, 14 Mar 2006 21:15:19 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJLXf-0006FP-GN for simple@ietf.org; Tue, 14 Mar 2006 21:15:19 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IW500B2PD9DNW@szxga03-in.huawei.com> for simple@ietf.org; Wed, 15 Mar 2006 10:22:25 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IW500H7TD9CDA@szxga03-in.huawei.com> for simple@ietf.org; Wed, 15 Mar 2006 10:22:25 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IW500E7WDIJ0V@szxml02-in.huawei.com>; Wed, 15 Mar 2006 10:27:58 +0800 (CST) Date: Wed, 15 Mar 2006 10:14:56 +0800 From: Xiao Wang Subject: RE: [Simple] "offline" watcher info In-reply-to: <015901c64753$980c7a10$4345fea9@matrix2> To: =?iso-8859-1?Q?'Gustavo_Garc=EDa_Bernardo'?= Message-id: <00ae01c647d6$40ffd7c0$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcZHU5fa4UtBMHhzT2yye+UOgmCxrQAgLqZw X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Errors-To: simple-bounces@ietf.org IM and Presence are different functions, they are usually used together. = I think as long as ua can connect to net, whether IM offline is not effect = on the watcher info achieved. =20 If ua can not connect to net, it only sets access policy to presence = server beforehand. Xiao ________________________________________ From: Gustavo Garc=EDa Bernardo [mailto:ggb@tid.es]=20 Sent: Tuesday, March 14, 2006 6:40 PM To: simple@ietf.org Subject: [Simple] "offline" watcher info Hi, For implementing a SIP Instant Messenger it is necessary that a user A = could detect when other user B is subscribing to his presence, so that A could authorize or deny it modifying his presence rules (according to draft-ietf-simple-presence-rules-04).=A0=20 I think this could be achieved with watcher info (RFC3857) if A is = online (and subscribed to his watcher info) at B subscription time, but How = should it works if A is offline at these moment?=A0=20 Thanks Gustavo Garc=EDa _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 14 22:13:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJMRg-0006zY-4Y; Tue, 14 Mar 2006 22:13:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJMRf-0006xC-0i for simple@ietf.org; Tue, 14 Mar 2006 22:13:07 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJMRc-000818-M8 for simple@ietf.org; Tue, 14 Mar 2006 22:13:06 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 14 Mar 2006 22:13:05 -0500 X-IronPort-AV: i="4.02,192,1139202000"; d="scan'208"; a="84133408:sNHT32081464" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2F3D1We017452; Tue, 14 Mar 2006 22:13:04 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Mar 2006 22:13:01 -0500 Received: from [192.168.1.101] ([10.86.241.73]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Mar 2006 22:13:00 -0500 Message-ID: <4417863C.6070800@cisco.com> Date: Tue, 14 Mar 2006 22:13:00 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gustavo_Garc=EDa_Bernardo?= Subject: Re: [Simple] "offline" watcher info References: <015901c64753$980c7a10$4345fea9@matrix2> In-Reply-To: <015901c64753$980c7a10$4345fea9@matrix2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Mar 2006 03:13:00.0917 (UTC) FILETIME=[5DD4B250:01C647DE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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: , Errors-To: simple-bounces@ietf.org This is why watcherinfo defines the 'waiting' state. The problem of offline authorization and how 'waiting' solves it is discussed in Section 4.7.1 of RFC 3857. -Jonathan R. Gustavo García Bernardo wrote: > Hi, > > > > For implementing a SIP Instant Messenger it is necessary that a user > A could detect when other user B is subscribing to his presence, so > that A could authorize or deny it modifying his presence rules > (according to draft-ietf-simple-presence-rules-04). > > > > I think this could be achieved with watcher info (RFC3857) if A is > online (and subscribed to his watcher info) at B subscription time, > but How should it works if A is offline at these moment? > > > > Thanks > > > > Gustavo García > > > > > > > > > ------------------------------------------------------------------------ > > > _______________________________________________ Simple mailing list > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 15 05:25:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJTBs-0003c9-5A; Wed, 15 Mar 2006 05:25:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJTBq-0003c4-MN for simple@ietf.org; Wed, 15 Mar 2006 05:25:14 -0500 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJTBp-0003kK-Dr for simple@ietf.org; Wed, 15 Mar 2006 05:25:14 -0500 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 Date: Wed, 15 Mar 2006 11:25:10 +0100 Message-ID: <31721CD4D0090B4BA32CBA5E2C40AE9001EC0F49@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Filtering: the purpose of the 'ns-binding' element Thread-Index: AcXpztkvQs5m0O8JRsGwN9/Az1qqhA== From: To: X-OriginalArrivalTime: 15 Mar 2006 10:25:11.0782 (UTC) FILETIME=[BDD4B060:01C6481A] X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Simple] Filtering: the purpose of the 'ns-binding' element 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: , Errors-To: simple-bounces@ietf.org Hi, each filter-set document may contain the 'ns-binding' element. Considering that the XML document itself has the means of defining namespace abbreviations (xmlns attributes), I do not completely understand the purpose of this element. Could anyone explain the importance of the 'ns-binding' element? Isn't it redundant? Why it doesn't suffice to extract namespace abbreviations from the xmlns attributes? Thanks, in advance. Regards, Michal Burda _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 15 06:59:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJUew-0008ES-44; Wed, 15 Mar 2006 06:59:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJUet-0008EM-T4 for simple@ietf.org; Wed, 15 Mar 2006 06:59:19 -0500 Received: from ee.oulu.fi ([130.231.61.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJUes-0006ew-F6 for simple@ietf.org; Wed, 15 Mar 2006 06:59:19 -0500 Received: from sinfpc9 (s-inf-pc9 [130.231.50.139]) by ee.oulu.fi (8.13.5/8.13.5) with ESMTP id k2FBwskW004691; Wed, 15 Mar 2006 13:58:54 +0200 (EET) From: "Jussi Ala-Kurikka" To: Subject: RE: [Simple] PIDFConn draft updated Date: Wed, 15 Mar 2006 13:58:48 +0200 Organization: MediaTeam/University of Oulu Message-ID: <003401c64827$d4f97340$8b32e782@sinfpc9> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 thread-index: AcZEJGMscNwCYMcvQjaPy/qImlzWEQD8/LmAAAOUbbA= X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: , Errors-To: simple-bounces@ietf.org > The changes were made based on the feedback we got in the Vancouver > meeting, mainly focusing on the additional "range" > attribute in the element. We wanted to make it possible to also include measured values. Theoretical values can give some clue as to what kind of performance can be expected, but in many cases the theoretical values are too optimistic. Measurements could give more useful information, and maybe parameters other than throughput could also be included. > There are now also use cases as concrete examples of > PIDFConn usage. We look forward > to any comments, corrections, complaints or additions, > especially concerning the newly introduced attribute. The use cases are exemplary but by no means exhaustive. Also, they were quite user/application centric. PIDFConn's applications in optimized connectivity management were not discussed yet. -Jussi _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 15 13:30:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJalA-0002dQ-FS; Wed, 15 Mar 2006 13:30:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJal8-0002Yb-DR for simple@ietf.org; Wed, 15 Mar 2006 13:30:10 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJal7-0002XL-0O for simple@ietf.org; Wed, 15 Mar 2006 13:30:10 -0500 Received: from mail3.microsoft.com ([157.54.66.7]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 15 Mar 2006 10:30:08 -0800 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 10:30:07 -0800 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 10:30:07 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 10:30:06 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 10:30:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Mar 2006 10:30:05 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IM delivery reports for conferencing thread-index: AcZIXnrWk4Edv+MKQXKwpcPB5yltIQ== From: "Sean Olson" To: , X-OriginalArrivalTime: 15 Mar 2006 18:30:06.0460 (UTC) FILETIME=[7B9C3BC0:01C6485E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: simple@ietf.org Subject: [Simple] IM delivery reports for conferencing 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: , Errors-To: simple-bounces@ietf.org Looking at: http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts-00.tx t=20 And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt Neither seems to address the use case of an "exploder" or IM conferencing where a single IM may have multiple recipients. My suggestion is that the schema you choose for the notification allow multiple delivery notifications to be batched together with each entry distringuished by the recipient URI. For example: For Draft-khartabil-simple-im-receipts-00 34jk324j read 200 The message has been read error 415 The message could not be delivered =20 Or, for Draft-burger-simple-imdn-03 1542af3e8b@eburger@example.com im:hisham.khartabil@example.net read im:eric.burger@example.net read Sorry if this has been discussed before. Was there a reason this was omitted previously? Thanks, Sean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 15 15:05:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJcEr-0007AN-0x; Wed, 15 Mar 2006 15:04:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJcEp-0007AI-T8 for simple@ietf.org; Wed, 15 Mar 2006 15:04:55 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJcEp-0005Qr-F1 for simple@ietf.org; Wed, 15 Mar 2006 15:04:55 -0500 X-IronPort-AV: i="4.02,195,1139202000"; d="scan'208,217"; a="30075506:sNHT52746892" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Mar 2006 15:06:42 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470231C19E@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IM delivery reports for conferencing Thread-Index: AcZIXnrWk4Edv+MKQXKwpcPB5yltIQADX9Bl From: "Burger, Eric" To: "Sean Olson" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: simple@ietf.org Subject: [Simple] RE: IM delivery reports for conferencing 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="===============1158612383==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1158612383== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6486B.FA631E1E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6486B.FA631E1E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That was the key, principal difference between the two approaches. IMDN = was designed to support that model, the other was not. Unfortunately, the consensus of the work group was that although fullt = specified, people felt that the complexity of batching (time-outs and = privacy) was not worth the effort. Thus I ripped it out of IMDN. That said, I left hooks in IMDN to replace the functionality in a = backwards-compatible way at a later date. Some want those hooks pulled = out, but I'm resisring. -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Wed Mar 15 13:32:01 2006 To: hisham.khartabil@telio.no; Burger, Eric Cc: simple@ietf.org Subject: IM delivery reports for conferencing Looking at: http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts-00.tx t=20 And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt Neither seems to address the use case of an "exploder" or IM conferencing where a single IM may have multiple recipients. My suggestion is that the schema you choose for the notification allow multiple delivery notifications to be batched together with each entry distringuished by the recipient URI. For example: For Draft-khartabil-simple-im-receipts-00 34jk324j read 200 The message has been read error 415 The message could not be delivered =20 Or, for Draft-burger-simple-imdn-03 1542af3e8b@eburger@example.com im:hisham.khartabil@example.net read im:eric.burger@example.net read Sorry if this has been discussed before. Was there a reason this was omitted previously? Thanks, Sean ------_=_NextPart_001_01C6486B.FA631E1E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: IM delivery reports for conferencing

That was the key, principal difference between the two = approaches.  IMDN was designed to support that model, the other was = not.

Unfortunately, the consensus of the work group was that although fullt = specified, people felt that the complexity of batching (time-outs and = privacy) was not worth the effort.  Thus I ripped it out of = IMDN.

That said, I left hooks in IMDN to replace the functionality in a = backwards-compatible way at a later date.  Some want those hooks = pulled out, but I'm resisring.

 -----Original Message-----
From:   Sean Olson [mailto:Sean.Olson@microsoft.com<= /A>]
Sent:   Wed Mar 15 13:32:01 2006
To:     hisham.khartabil@telio.no; Burger, Eric
Cc:     simple@ietf.org
Subject:        IM delivery reports = for conferencing


Looking at:
http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receip= ts-00.tx
t
And: = http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt

Neither seems to address the use case of an "exploder" or = IM
conferencing where a single IM may have multiple recipients. My
suggestion is that the schema you choose for the notification allow
multiple delivery notifications to be batched together with each = entry
distringuished by the recipient URI.

For example:

For Draft-khartabil-simple-im-receipts-00

         = <status-receipt>
            = <message-id>34jk324j</message-id>
            = <recipient uri=3D"bob@example.com">
            &= nbsp;    <type>read</type>
            &= nbsp;    <status>200</status>
            &= nbsp;    <note lang=3D"en">The message = has been read</note>
            = </recipient>
            = <recipient uri=3D"alice@example.com">
            &= nbsp;    <type>error</type>
            &= nbsp;    <status>415</status>
            &= nbsp;    <note lang=3D"en">The message = could not be
delivered</note>
            = </recipient>   
         = </status-receipt>

Or, for Draft-burger-simple-imdn-03

        <imdn>
            = <original-message-id>
            &= nbsp;  1542af3e8b@eburger@example.com
            = </original-message-id>
            = <reporting-uas = uri=3D"im:hisham.khartabil@example.net">
            &= nbsp;  <original-recipient-uri>
            &= nbsp;     im:hisham.khartabil@example.net
            &= nbsp;  </original-recipient-uri>
            &= nbsp;  <disposition>read</disposition>
            = </reporting-uas>
            = <reporting-uas uri=3D"im:eric.burger@example.net">
            &= nbsp;  <original-recipient-uri>
            &= nbsp;     im:eric.burger@example.net
            &= nbsp;  </original-recipient-uri>
            &= nbsp;  <disposition>read</disposition>
            = </reporting-uas>
        </imdn>

Sorry if this has been discussed before. Was there a reason this was
omitted previously?

Thanks,
Sean

------_=_NextPart_001_01C6486B.FA631E1E-- --===============1158612383== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1158612383==-- From simple-bounces@ietf.org Wed Mar 15 16:08:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJdDs-0006NJ-7w; Wed, 15 Mar 2006 16:08:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJdDr-0006MK-9C for simple@ietf.org; Wed, 15 Mar 2006 16:07:59 -0500 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJdDp-0007lr-Sq for simple@ietf.org; Wed, 15 Mar 2006 16:07:59 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 15:07:57 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 15 Mar 2006 15:07:56 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 15:07:56 -0600 Message-ID: From: "Thomson, Martin" To: Date: Wed, 15 Mar 2006 15:06:24 -0600 Subject: RE: [Simple] Filtering: the purpose of the 'ns-binding' element MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 15 Mar 2006 21:07:56.0053 (UTC) FILETIME=[87ED7450:01C64874] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Simple] Filtering: the purpose of the 'ns-binding' element Thread-Index: AcXpztkvQs5m0O8JRsGwN9/Az1qqhBepT2dg X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Content-Type: multipart/mixed; boundary="===============1921102262==" Errors-To: simple-bounces@ietf.org --===============1921102262== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SSB0aGluayB0aGF0IGl0IGlzIG5vdCBvbmx5IHJlZHVuZGFudCwgYnV0IGRhbmdlcm91cy4gIEl0 IGlzIHBvc3NpYmxlIHRvIGhhdmUgY29udHJhZGljdG9yeSB2YWx1ZXMgaW4gdGhlcmUgYW5kIGlu IHRoZSB4bWxuczouLi4gYXR0cmlidXRlcy4gIEkgY2FuJ3QgdGhpbmsgb2YgYSBnb29kIHJlYXNv biB0byBpbmNsdWRlIHN1Y2ggYW4gZWxlbWVudCBpbiB0aGlzIGNvbnRleHQuDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWljaGFsLkJ1cmRhQHRpZXRvZW5hdG9yLmNv bSBbbWFpbHRvOk1pY2hhbC5CdXJkYUB0aWV0b2VuYXRvci5jb21dDQo+IFNlbnQ6IFdlZG5lc2Rh eSwgMTUgTWFyY2ggMjAwNiA5OjI1IFBNDQo+IFRvOiBzaW1wbGVAaWV0Zi5vcmcNCj4gU3ViamVj dDogW1NpbXBsZV0gRmlsdGVyaW5nOiB0aGUgcHVycG9zZSBvZiB0aGUgJ25zLWJpbmRpbmcnIGVs ZW1lbnQNCj4gDQo+IEhpLA0KPiANCj4gZWFjaCBmaWx0ZXItc2V0IGRvY3VtZW50IG1heSBjb250 YWluIHRoZSAnbnMtYmluZGluZycgZWxlbWVudC4NCj4gQ29uc2lkZXJpbmcgdGhhdCB0aGUgWE1M IGRvY3VtZW50IGl0c2VsZiBoYXMgdGhlIG1lYW5zIG9mIGRlZmluaW5nDQo+IG5hbWVzcGFjZSBh YmJyZXZpYXRpb25zICh4bWxucyBhdHRyaWJ1dGVzKSwgSSBkbyBub3QgY29tcGxldGVseQ0KPiB1 bmRlcnN0YW5kIHRoZSBwdXJwb3NlIG9mIHRoaXMgZWxlbWVudC4NCj4gDQo+IENvdWxkIGFueW9u ZSBleHBsYWluIHRoZSBpbXBvcnRhbmNlIG9mIHRoZSAnbnMtYmluZGluZycgZWxlbWVudD8gSXNu J3QNCj4gaXQgcmVkdW5kYW50PyBXaHkgaXQgZG9lc24ndCBzdWZmaWNlIHRvIGV4dHJhY3QgbmFt ZXNwYWNlIGFiYnJldmlhdGlvbnMNCj4gZnJvbSB0aGUgeG1sbnMgYXR0cmlidXRlcz8NCj4gDQo+ IFRoYW5rcywgaW4gYWR2YW5jZS4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBNaWNoYWwgQnVyZGEN Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IFNpbXBsZSBtYWlsaW5nIGxpc3QNCj4gU2ltcGxlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVj aXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Ig b3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0 IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxl dGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMg cHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21m Ml0= --===============1921102262== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1921102262==-- From simple-bounces@ietf.org Wed Mar 15 16:49:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJdrV-000752-Vj; Wed, 15 Mar 2006 16:48:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJdrU-00074r-RV for simple@ietf.org; Wed, 15 Mar 2006 16:48:56 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJdrT-00009q-4r for simple@ietf.org; Wed, 15 Mar 2006 16:48:56 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id D390E194458 for ; Wed, 15 Mar 2006 22:48:53 +0100 (CET) Received: from [10.75.117.242] ([216.1.176.230]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 22:47:15 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Date: Wed, 15 Mar 2006 22:49:19 +0100 To: "Sean Olson" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 15 Mar 2006 21:47:16.0196 (UTC) FILETIME=[06AEB240:01C6487A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: eburger@brooktrout.com, simple@ietf.org Subject: [Simple] Re: IM delivery reports for conferencing 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: , Errors-To: simple-bounces@ietf.org On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: > > Looking at: > http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts > -00.tx > t > And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt > > Neither seems to address the use case of an "exploder" or IM > conferencing where a single IM may have multiple recipients. My > suggestion is that the schema you choose for the notification allow > multiple delivery notifications to be batched together with each entry > distringuished by the recipient URI. It does address it to an extent. That's what the "uri" attribute is there for. If we want to allow aggregation of receipts before sending the receipt to the IM sender, then we also need to start thinking about what the sender wants and how to indicate it in the IM itself. Hisham > > For example: > > For Draft-khartabil-simple-im-receipts-00 > > > 34jk324j > > read > 200 > The message has been read > > > error > 415 > The message could not be > delivered > > > > Or, for Draft-burger-simple-imdn-03 > > > > 1542af3e8b@eburger@example.com > > > > im:hisham.khartabil@example.net > > read > > > > im:eric.burger@example.net > > read > > > > Sorry if this has been discussed before. Was there a reason this was > omitted previously? > > Thanks, > Sean > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 16 11:33:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJvPU-0002UD-3H; Thu, 16 Mar 2006 11:33:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJvPT-0002Tn-7A for simple@ietf.org; Thu, 16 Mar 2006 11:33:11 -0500 Received: from asg03.asg.bellsouth.net ([65.83.231.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJvPS-0007zh-0I for simple@ietf.org; Thu, 16 Mar 2006 11:33:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Mar 2006 11:33:09 -0500 Message-ID: <91A7043427443A4EAF6E7DA4D00B534D6E8BE4@asg03.asg.bellsouth.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of draft-ietf-simple-event-list-07 and draft-ietf-simple-list-usage-05 Thread-Index: AcZJF09LToxRewxHSa+2b+nW/ra3cQ== From: "Tim Wong" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Subject: [Simple] Status of draft-ietf-simple-event-list-07 and draft-ietf-simple-list-usage-05 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="===============0020338500==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0020338500== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64917.4FA05E2E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64917.4FA05E2E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Can someone tell me what is the status of both of following drafts? 1) draft-ietf-simple-event-list-07=20 2) draft-ietf-simple-list-usage-05 =20 Thanks, =20 Tim Wong =20 =20 ------_=_NextPart_001_01C64917.4FA05E2E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

Can someone tell me what is the status of both of = following drafts?

1)       = draft-ietf-simple-event-list= -07

2)       = draft-ietf-simple-list-usage= -05

 

Thanks,

 

Tim Wong

 

 

------_=_NextPart_001_01C64917.4FA05E2E-- --===============0020338500== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0020338500==-- From simple-bounces@ietf.org Thu Mar 16 11:51:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJvhG-0005Ke-8l; Thu, 16 Mar 2006 11:51:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJvhE-0005FU-NY for simple@ietf.org; Thu, 16 Mar 2006 11:51:32 -0500 Received: from web8903.mail.in.yahoo.com ([203.84.221.31]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FJvhC-0008Pi-Kt for simple@ietf.org; Thu, 16 Mar 2006 11:51:32 -0500 Received: (qmail 322 invoked by uid 60001); 16 Mar 2006 16:51:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SbPS7oRhDqqm6hcwE3OgSSvW5WjJPIX9cCMl5cSlOfriTMUn3J54zC4w5HC8thbqtJenE8X0vUliOiaL5f2I3W9Hwg7vB/4VyQlQLs3D2iWPNWKuXTwvRWVXYo2RcOXEpIKi3e9lLSwoE5E2XC3pbrrngnxxsMzK8kCsQqxWDxs= ; Message-ID: <20060316165127.320.qmail@web8903.mail.in.yahoo.com> Received: from [210.214.40.84] by web8903.mail.in.yahoo.com via HTTP; Thu, 16 Mar 2006 16:51:27 GMT Date: Thu, 16 Mar 2006 16:51:27 +0000 (GMT) From: Thejeswara Reddy To: simple@ietf.org, sip ietf MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Simple] Simple and MBUS 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="===============0015629098==" Errors-To: simple-bounces@ietf.org --===============0015629098== Content-Type: multipart/alternative; boundary="0-935317296-1142527887=:96083" Content-Transfer-Encoding: 8bit --0-935317296-1142527887=:96083 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit HI, How about supporting MBUS IN SIP&SIMPLE. MBUS-->Message bus allows Device co-ordination. using SIMPLE can we extend it for interactive Session between Devices. thanks theja --------------------------------- Jiyo cricket on Yahoo! India cricket Yahoo! Messenger Mobile Stay in touch with your buddies all the time. --0-935317296-1142527887=:96083 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit HI,
      How about supporting MBUS IN SIP&SIMPLE.

MBUS-->Message bus allows Device co-ordination.

using SIMPLE can we extend it for  interactive Session between Devices.

thanks
theja

Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time. --0-935317296-1142527887=:96083-- --===============0015629098== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0015629098==-- From simple-bounces@ietf.org Thu Mar 16 13:58:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJxfu-000253-RU; Thu, 16 Mar 2006 13:58:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJxfs-00024y-SC for simple@ietf.org; Thu, 16 Mar 2006 13:58:16 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJxfr-0004Hb-J3 for simple@ietf.org; Thu, 16 Mar 2006 13:58:16 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2GIw8OL000226; Thu, 16 Mar 2006 12:58:08 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 16 Mar 2006 18:58:08 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0124F9611@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Tim Wong , simple@ietf.org Subject: RE: [Simple] Status of draft-ietf-simple-event-list-07 and draft- ietf-simple-list-usage-05 Date: Thu, 16 Mar 2006 18:58:07 -0000 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: 8abaac9e10c826e8252866cbe6766464 Cc: 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: , Errors-To: simple-bounces@ietf.org You can answer the first question by entering your query in: https://datatracker.ietf.org/public/pidtracker.cgi You will also find the other one there by getting the draft name correct (draft-ietf-simple-xcap-list-usage or just enter list-usage in the file name box). You will also find further information on both drafts here: http://www.rfc-editor.org/queue.html which indicates specifically that they are both waiting on referenced documents. regards Keith -----Original Message----- From: Tim Wong [mailto:twong@asg.bellsouth.net] Sent: 16 March 2006 16:33 To: simple@ietf.org Subject: [Simple] Status of draft-ietf-simple-event-list-07 and draft-ietf-simple-list-usage-05 All, Can someone tell me what is the status of both of following drafts? 1) draft-ietf-simple-event-list-07 2) draft-ietf-simple-list-usage-05 Thanks, Tim Wong _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 16 14:46:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJyQU-0005fL-Do; Thu, 16 Mar 2006 14:46:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJyQT-0005fG-OH for simple@ietf.org; Thu, 16 Mar 2006 14:46:25 -0500 Received: from asg03.asg.bellsouth.net ([65.83.231.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJyQR-00064a-F5 for simple@ietf.org; Thu, 16 Mar 2006 14:46:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [Simple] Status of draft-ietf-simple-event-list-07 and draft-ietf-simple-list-usage-05 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Mar 2006 14:46:22 -0500 Message-ID: <91A7043427443A4EAF6E7DA4D00B534D6E8C5F@asg03.asg.bellsouth.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Status of draft-ietf-simple-event-list-07 and draft-ietf-simple-list-usage-05 Thread-Index: AcZJK5TIfxUB8PFwTGeyH1VpAmFxrQABXT9Q From: "Tim Wong" To: "Drage, Keith \(Keith\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: 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: , Errors-To: simple-bounces@ietf.org Keith, Thanks for your suggestion, but I have queried both of those drafts and they both have expired. draft-ietf-simple-event-list-07 expired in June 15, 2005 draft-ietf-simple-xcap-list-usage-05 expired in August 8. 2005 That is the last known status. I just don't know what the status of those two drafts going forward is. Thanks, -Tim -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 Sent: Thursday, March 16, 2006 1:58 PM To: Tim Wong; simple@ietf.org Subject: RE: [Simple] Status of draft-ietf-simple-event-list-07 and draft-ietf-simple-list-usage-05 You can answer the first question by entering your query in: https://datatracker.ietf.org/public/pidtracker.cgi You will also find the other one there by getting the draft name correct (draft-ietf-simple-xcap-list-usage or just enter list-usage in the file name box). You will also find further information on both drafts here: http://www.rfc-editor.org/queue.html which indicates specifically that they are both waiting on referenced documents. regards Keith -----Original Message----- From: Tim Wong [mailto:twong@asg.bellsouth.net] Sent: 16 March 2006 16:33 To: simple@ietf.org Subject: [Simple] Status of draft-ietf-simple-event-list-07 and draft-ietf-simple-list-usage-05 All, Can someone tell me what is the status of both of following drafts? 1) draft-ietf-simple-event-list-07=20 2) draft-ietf-simple-list-usage-05 =20 Thanks, =20 Tim Wong =20 =20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 16 15:07:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJylE-0007NC-KL; Thu, 16 Mar 2006 15:07:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJylE-0007N7-09 for simple@ietf.org; Thu, 16 Mar 2006 15:07:52 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJylC-0006w7-Ot for simple@ietf.org; Thu, 16 Mar 2006 15:07:51 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJygw-0001Vq-2K; Thu, 16 Mar 2006 20:03:26 +0000 To: "Tim Wong" Subject: Re: [Simple] Status of draft-ietf-simple-event-list-07 and draft-ietf-simple-list-usage-05 Date: Thu, 16 Mar 2006 12:03:26 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "Drage, Keith \(Keith\)" , 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: , Errors-To: simple-bounces@ietf.org Message-Id: Tim, > Keith > > Thanks for your suggestion, but I have queried both of those drafts and > they both have expired. > > draft-ietf-simple-event-list-07 expired in June 15, 2005 > draft-ietf-simple-xcap-list-usage-05 expired in August 8. 2005 > > That is the last known status. I just don't know what the status of > those two drafts going forward is. Don't worry about the statement inside the draft that says Expires: Once the document is approved and on the RFC Editor Queue, this date is no longer meaningful and it is supposed to be ignored. I've suggested to a group in the IETF working on document issues that we fix these. Your experience of thinking the draft expired is not uncommon. Allison _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 16 15:14:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJyrT-0003LT-K3; Thu, 16 Mar 2006 15:14:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJyrT-0003K3-8b for simple@ietf.org; Thu, 16 Mar 2006 15:14:19 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJyrR-00077W-Iw for simple@ietf.org; Thu, 16 Mar 2006 15:14:19 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 3B655194468 for ; Thu, 16 Mar 2006 21:14:16 +0100 (CET) Received: from [10.75.117.242] ([216.1.176.230]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Mar 2006 21:12:36 +0100 In-Reply-To: <31721CD4D0090B4BA32CBA5E2C40AE9001EC016B@carrera.eu.tieto.com> References: <31721CD4D0090B4BA32CBA5E2C40AE9001EC016B@carrera.eu.tieto.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <54d7a7e21abd554c9e3efc6625e684ab@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Issue with comparisons for triggerring Date: Thu, 16 Mar 2006 21:14:46 +0100 To: X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 16 Mar 2006 20:12:36.0861 (UTC) FILETIME=[F7F2B2D0:01C64935] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: jari.urpalainen@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: , Errors-To: simple-bounces@ietf.org Michal is correct in his observation. The NOTIFY at step 7 should not be sent. As far as the subscriber is concerned, the is C (receiving the NOTIFY at step 3). There is no new information given to the subscriber at step 7 that s/he requested. Hisham On Mar 13, 2006, at 12:28 PM, wrote: >> -----Original Message----- >> From: Jari Urpalainen [mailto:jari.urpalainen@nokia.com] >> Sent: Friday, March 10, 2006 9:56 AM >> To: ext Sean Leahy >> Cc: simple@ietf.org >> Subject: Re: [Simple] Issue with comparisons for triggerring >> >> Hisham and Sean! >> >> For me the current text is eligible enough although there are some >> implicit rules to interpret (and I think I'll understand the > intention, >> but correct me if my example is wrong ...). If this really needs to be >> clarified (which may not be likely given the 48hours state), an > example >> would be worth a xxx of words: >> >> Given the state can have values A, B or C and a transition from A to C >> is the trigger rule: >> >> state | action >> --------------- >> 1: A | notify (initial subscription) >> 2: B | - >> 3: C | notify >> 4: B | - >> 5: C | - >> 6: A | - >> 7: C | notify >> --------------- > > I do not completely understand, why the third notification is sent to > the subscriber. draft-ietf-simple-filter-format-05 says: > > "The element is used to identify the XML element or > attribute, > from the package specific XML document, whose value MUST change, > compared to the "previous XML document", in order to activate the > trigger and cause the content to be delivered. Previous XML document > in > this context refers to the last XML document that was selected for > delivery to that specific subscription before any filter was applied to > it." > > As far as I understand the above cited text, the trigger in step (7) > has > to be evaluated accordingly to the second notification (step 3), > because > it is the last XML document that was selected for delivery. Thus, if > comparing states from step 3 and step 7, there is no difference (both > are "C"), so the last notification shouldn't be sent. In fact, no > notification would be sent ever unless someone changes the triggering > criteria. Btw, it sounds very strange to me... > > >> >> Similar tables could be given with numbers with . But as I said > I'm >> contented with the current text although in general I'll prefer good >> examples over text (lazy implementer ;-)). >> br, >> Jari >> >> >> >> >> _______________________________________________ >> 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 Mar 16 18:32:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1x8-0001zZ-Bh; Thu, 16 Mar 2006 18:32:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1x7-0001zP-7U for simple@ietf.org; Thu, 16 Mar 2006 18:32:21 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK1x6-00077e-S1 for simple@ietf.org; Thu, 16 Mar 2006 18:32:21 -0500 Received: from [72.1.129.100] (dsl001-129-100.dfw1.dsl.speakeasy.net [72.1.129.100]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.3) with ESMTP id k2GNWHfV015684 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 16 Mar 2006 17:32:17 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: <44029071.3080507@cisco.com> References: <4402885A.4010706@gmail.com> <44029071.3080507@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3440F729-E77E-412D-AE96-8D70AECF8820@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple]Question on MESSAGE Date: Thu, 16 Mar 2006 17:32:10 -0600 To: Michael Zhou X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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: , Errors-To: simple-bounces@ietf.org Sorry for the late response. Creating a dialog with INVITE for the sole purpose of sending MESSAGE requests is not a "standard" behavior, and is explicitly recommended against RFC 3428. This is not to say that there are not proprietary implementations that do just that, but they are, uhm, proprietary. The SIMPLE standard for message sessions is to use MSRP as the message transport. MSRP sessions _are_ created using INVITE and SDP. The MSRP messages are not sent in the SIP dialog, rather they are sent as part of an associated media session, much the same as how it is done for RTP. On Feb 26, 2006, at 11:38 PM, Michael Zhou wrote: > If you want to do session mode IM, then you need to establish the > session using INVITE and send IM inside the INVITE dialog. Microsoft > Mesenger implements session mode IM. > > There is another mode, called pager mode IM, where you don't have to > send INVITE prior to MESSAGE. All MESSAGE's in this case are out of > any > dialog. Gaim and Sametime and others implements pager mode IM. > > Michael > > > > Ren-Huang Liou wrote: >> Hi, >> >> Do I need to send INVITE in order to establish session, before I >> send MESSAGE request? >> Two internet drafts about this issue has been expired for a long >> time. >> (SDP Extensions for SIP Instant Message Sessions, SIP Instant >> Message Sessions) >> >> Does it mean that I don't need to send INVITE, before I send MESSAGE? >> >> Thanks in advance >> >> Best regards, >> Ren-Huang Liou >> >> >> >> _______________________________________________ >> 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 Mar 16 19:33:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK2uY-0008Tk-8m; Thu, 16 Mar 2006 19:33:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK2uX-0008Ta-2h for simple@ietf.org; Thu, 16 Mar 2006 19:33:45 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK2uW-0000RZ-KP for simple@ietf.org; Thu, 16 Mar 2006 19:33:45 -0500 Received: from [72.1.129.100] (dsl001-129-100.dfw1.dsl.speakeasy.net [72.1.129.100]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.3) with ESMTP id k2H0XhMU029348 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 16 Mar 2006 18:33:43 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <35A9B2BB-1576-4A26-B7FB-003BD44B4A94@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP Report Model Date: Thu, 16 Mar 2006 18:33:36 -0600 To: Amitkumar.Goel@infineon.com X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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: , Errors-To: simple-bounces@ietf.org Sorry for the late response. I somehow failed to notice your email until now. Comments inline: On Feb 2, 2006, at 10:59 PM, Amitkumar.Goel@infineon.com wrote: > Hi, > > There are some more doubts which are still not clear. More Inline > > Regards, > Amit Kumar Goel > Infineon Technology, > Bangalore > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > Behalf > Of Ben Campbell > Sent: Monday, January 23, 2006 9:15 PM > To: Goel Amitkumar (IFIN CSW WS) > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP Report Model > > > Hi, > > The work group discussed this issue in detail some time ago. I offer > the following to describe the result of that discussion. More inline: > > > On Jan 10, 2006, at 5:55 AM, Amitkumar.Goel@infineon.com wrote: > >> Hi All, >> >> This is regarding MSRP Report Model. MSRP draft says receiver MUST >> send REPORT (success/failure) depending upon the "Success-Report" >> and > >> "Failure-Report" header field values in the SEND request. But in >> case > >> receiver does not want to generate the reports, there should be a >> way /some ways of indicating the same (may be this was already >> discussed earlier, but I am not aware of). There can be many reasons >> for the receiver not to generate REPORT for incoming SEND request. > > The issue is, if the sender requests success-reports, the sender is > requesting reliable delivery of the message. This makes the REPORT > effectively part of a end-to-end transaction. If the sender does not > receive one in a reasonable period of time, it is likely to attempt > to attempt to restart the session, resend the content, etc. > > Furthermore, a positive delivery report does not indicate that the > receiving human has actually seen the message. Only that the endpoint > has received it. In this sense, you can think of a positive report to > be akin to a SIP 200 OK response, which is certainly not optional. > > > > This makes sense. If we have a mechanism to know about the > reliable delivery of > message, ideally specification should not mandate the use of TCP > as the transport protocol. > There should be option to use UDP and any other transport > protocol. > This issue I raised sometime back also. > > > TCP was specified mainly for congestion management reasons. The IESG has been discouraging the use of non-congestion-controlled transport protocols except for some very specific applications for some time now. >> >> 1. Congestion on the receiver side > > I don't think we need an exception for congestion--the endpoint may > fail to live up to any aspect of the protocol when congested. We > would need to put the same exception on everything else. > >> 2. Service Provider may charge for per unit data transferred. > > The REPORT request is typically small. Also MSRP will likely be used > with presence, which will create quite a bit of traffic. Any > additional cost for REPORT requests will probably fall into the noise. > > >> 3. Due to some security or privacy reason >> > > Again, REPORT does not indicate the user has seen the message. It can > be sent before rendering of the content. Furthermore, an MSRP session > will only exist if negotiated with SIP or some other rendez-vous > protocol. Once an endpoint has explicitly indicated its willingness > to participate in an MSRP session, actually sending REPORT requests > does not seem to leak any information that has not already been > freely given. > > >> >> We MAY consider two solutions: >> 1. Negotiate Sending Reports during session setup and/or >> > > The working group discussed this some time back, and chose not to > include a negotiation mechanism. > > > > Can you please let us know what were the points based on which > it was decided not to include this negotiation or the pointers to such > information shall be appreciated. > > > The consensus was the value of such negotiation did not warrant the additional complexity. Yes, I know that seems laughable considering the complexity we put into other areas of MSRP--but the features introducing the other complexities had people championing them, and this did not. >> 2. Sender may be informed via transaction status messages indicating >> that receiver shall not generate the report. >> > > There are cases where no such transaction status message occurs, so > we cannot depend on this for negotiation. > > Hope this helps! > > Ben. > > _______________________________________________ > 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 Mar 16 19:34:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK2us-0000Ba-Tc; Thu, 16 Mar 2006 19:34:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK2ur-00007g-FW for simple@ietf.org; Thu, 16 Mar 2006 19:34:05 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK2ur-0000SU-4G for simple@ietf.org; Thu, 16 Mar 2006 19:34:05 -0500 Received: from [72.1.129.100] (dsl001-129-100.dfw1.dsl.speakeasy.net [72.1.129.100]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.3) with ESMTP id k2H0XhMV029348 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 16 Mar 2006 18:34:02 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <386B487A-F20A-4A88-8CD3-53CAF6B8B608@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Purpose of the namespace field in MSRP Date: Thu, 16 Mar 2006 18:34:00 -0600 To: Cullen Jennings X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: , Errors-To: simple-bounces@ietf.org I can't find a reference to an email, but this feature was strongly and explicitly requested by a few people, and did not seem to do much damage. On Feb 13, 2006, at 6:28 PM, Cullen Jennings wrote: > > I don't care one way or the other. So far it does not seem to be > used but > people did argue for it at one point. It might make it easier to GW > status > codes to other protocols but I sort of doubt it. > > > On 2/4/06 9:23 AM, "Jussi K. Virtanen" > wrote: > >> Hi, >> >> In MSRP, the Status header field in a REPORT request is divided into >> a namespace field and a status code field. Is there a compelling >> reason for the namespace field to exist at all? Has anyone come up >> with any valuable usage for it? To me it seems an odd nod toward >> bloat in otherwise reasonably compact grammar. >> >> >> Best Regards, >> >> -- >> Jussi K. Virtanen >> >> >> _______________________________________________ >> 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 Mar 17 04:54:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKBev-0007wj-3r; Fri, 17 Mar 2006 04:54:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKBet-0007we-U5 for simple@ietf.org; Fri, 17 Mar 2006 04:54:11 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKBes-0000ES-NK for simple@ietf.org; Fri, 17 Mar 2006 04:54:11 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2H9s80S027943; Fri, 17 Mar 2006 03:54:08 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 17 Mar 2006 09:54:08 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290838@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Allison Mankin'" , Tim Wong Subject: RE: [Simple] Status of draft-ietf-simple-event-list-07 and draft- ietf-simple-list-usage-05 Date: Fri, 17 Mar 2006 09:54:07 -0000 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: 9ed51c9d1356100bce94f1ae4ec616a9 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: , Errors-To: simple-bounces@ietf.org Until this gets fixed (or until IETF gets the publication queue down to zero length so that documents do not "expire" while they are in it), it is worth noting that in general, datatracker will either not return a result, or will return a result indicating "dead", if the draft really has expired. regards Keith > -----Original Message----- > From: Allison Mankin [mailto:mankin@psg.com] > Sent: 16 March 2006 20:03 > To: Tim Wong > Cc: Drage, Keith (Keith); simple@ietf.org > Subject: Re: [Simple] Status of draft-ietf-simple-event-list-07 and > draft-ietf-simple-list-usage-05 > > > Tim, > > > Keith > > > > Thanks for your suggestion, but I have queried both of > those drafts and > > they both have expired. > > > > draft-ietf-simple-event-list-07 expired in June 15, 2005 > > draft-ietf-simple-xcap-list-usage-05 expired in August 8. 2005 > > > > That is the last known status. I just don't know what the status of > > those two drafts going forward is. > > Don't worry about the statement inside the draft that says > > Expires: > > Once the document is approved and on the RFC Editor Queue, > this date is no longer meaningful and it is supposed to be ignored. > > I've suggested to a group in the IETF working on document issues that > we fix these. Your experience of thinking the draft expired is not > uncommon. > > Allison > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 17 05:09:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKBtD-0001uu-AN; Fri, 17 Mar 2006 05:08:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKBtB-0001uk-Rk for simple@ietf.org; Fri, 17 Mar 2006 05:08:57 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKBtA-0000oR-DI for simple@ietf.org; Fri, 17 Mar 2006 05:08:57 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2HA8nDt028292; Fri, 17 Mar 2006 12:08:53 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 12:08:48 +0200 Received: from mgw-int1.ntc.nokia.com ([172.21.143.96]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 17 Mar 2006 12:08:49 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2HA8l123712; Fri, 17 Mar 2006 12:08:47 +0200 (EET) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by kusti.research.nokia.com (Postfix) with ESMTP id EC6A993B75; Fri, 17 Mar 2006 12:08:46 +0200 (EET) Subject: RE: [Simple] Filtering: the purpose of the 'ns-binding' element From: Jari Urpalainen To: "ext Thomson, Martin" In-Reply-To: References: Content-Type: text/plain Date: Fri, 17 Mar 2006 12:08:46 +0200 Message-Id: <1142590126.3697.22.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2006 10:08:49.0160 (UTC) FILETIME=[C8F7F880:01C649AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: , Errors-To: simple-bounces@ietf.org On Wed, 2006-03-15 at 15:06 -0600, ext Thomson, Martin wrote: > I think that it is not only redundant, but dangerous. It is possible to have contradictory values in there and in the xmlns:... attributes. I can't think of a good reason to include such an element in this context. > > > -----Original Message----- > > From: Michal.Burda@tietoenator.com [mailto:Michal.Burda@tietoenator.com] > > Sent: Wednesday, 15 March 2006 9:25 PM > > To: simple@ietf.org > > Subject: [Simple] Filtering: the purpose of the 'ns-binding' element > > > > Hi, > > > > each filter-set document may contain the 'ns-binding' element. > > Considering that the XML document itself has the means of defining > > namespace abbreviations (xmlns attributes), I do not completely > > understand the purpose of this element. > > > > Could anyone explain the importance of the 'ns-binding' element? Isn't > > it redundant? Why it doesn't suffice to extract namespace abbreviations > > from the xmlns attributes? > > > > Thanks, in advance. > > > > Regards, > > > > Michal Burda > > The subscriber is not typically aware nor need to be aware about the used prefixes of published presence information. These prefixes are thus used for XPath evaluations during filtering, i.e. expanding the names within 'xpath' attribute values of and elements. One could argue that it were simpler just to use in-scope namespaces of those elements of filter document (just like in xml-patch-ops) but it is only a matter of taste. As such they are certainly needed. Using published presence document context here is not right. Still one option is to use "namespace-uri()" and "local-name()" functions but it leads to ugly looking and long rules. Default namespace is handled similarly to XPath 1.0, i.e. a selector "foo" locates a unqualified element. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 17 05:28:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKCCE-0007iS-OW; Fri, 17 Mar 2006 05:28:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKCCD-0007iN-LW for simple@ietf.org; Fri, 17 Mar 2006 05:28:37 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKCCC-0001Pk-6S for simple@ietf.org; Fri, 17 Mar 2006 05:28:37 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2HASWB8026375; Fri, 17 Mar 2006 12:28:35 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 12:28:32 +0200 Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 17 Mar 2006 12:28:31 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2HASV711229; Fri, 17 Mar 2006 12:28:31 +0200 (EET) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by kusti.research.nokia.com (Postfix) with ESMTP id 50BCF93B75; Fri, 17 Mar 2006 12:28:31 +0200 (EET) Subject: Re: [Simple] Issue with comparisons for triggerring From: Jari Urpalainen To: ext Hisham Khartabil In-Reply-To: <54d7a7e21abd554c9e3efc6625e684ab@telio.no> References: <31721CD4D0090B4BA32CBA5E2C40AE9001EC016B@carrera.eu.tieto.com> <54d7a7e21abd554c9e3efc6625e684ab@telio.no> Content-Type: text/plain Date: Fri, 17 Mar 2006 12:28:31 +0200 Message-Id: <1142591311.3697.36.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2006 10:28:31.0726 (UTC) FILETIME=[89D538E0:01C649AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: simple-bounces@ietf.org On Thu, 2006-03-16 at 21:14 +0100, ext Hisham Khartabil wrote: > Michal is correct in his observation. The NOTIFY at step 7 should not > be sent. As far as the subscriber is concerned, the is C (receiving the > NOTIFY at step 3). There is no new information given to the subscriber > at step 7 that s/he requested. > > Hisham ok, I was afraid that this wasn't unambiguous enough. So now I must change my mind (after re-reading the format i-d) that the text needs some clarification, i.e. it should say that the trigger rule is one-shot only (perhaps I was mislead by correspondence with electronics, e.g. monostable multivibrator ;-)). But I don't want to argue whether multi-shot or one-shot behavior is better... br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 17 05:32:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKCG0-0001iH-G2; Fri, 17 Mar 2006 05:32:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKCFy-0001ea-NG for simple@ietf.org; Fri, 17 Mar 2006 05:32:30 -0500 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKCFx-0001Sy-4H for simple@ietf.org; Fri, 17 Mar 2006 05:32:30 -0500 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] Filtering: the purpose of the 'ns-binding' element Date: Fri, 17 Mar 2006 11:32:26 +0100 Message-ID: <31721CD4D0090B4BA32CBA5E2C40AE9001EFA67A@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Filtering: the purpose of the 'ns-binding' element Thread-Index: AcZJq0Aqn44Xh11JSO2MNtMZdAhUBAAAUdaA From: To: X-OriginalArrivalTime: 17 Mar 2006 10:32:27.0871 (UTC) FILETIME=[169616F0:01C649AE] X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: jari.urpalainen@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: , Errors-To: simple-bounces@ietf.org > -----Original Message----- > From: Jari Urpalainen [mailto:jari.urpalainen@nokia.com] > Sent: Friday, March 17, 2006 11:09 AM > To: ext Thomson, Martin > Cc: Burda Michal; simple@ietf.org > Subject: RE: [Simple] Filtering: the purpose of the 'ns-binding' element >=20 > On Wed, 2006-03-15 at 15:06 -0600, ext Thomson, Martin wrote: > > I think that it is not only redundant, but dangerous. It is possible to > have contradictory values in there and in the xmlns:... attributes. I > can't think of a good reason to include such an element in this context. > > > > > -----Original Message----- > > > From: Michal.Burda@tietoenator.com > [mailto:Michal.Burda@tietoenator.com] > > > Sent: Wednesday, 15 March 2006 9:25 PM > > > To: simple@ietf.org > > > Subject: [Simple] Filtering: the purpose of the 'ns-binding' element > > > > > > Hi, > > > > > > each filter-set document may contain the 'ns-binding' element. > > > Considering that the XML document itself has the means of defining > > > namespace abbreviations (xmlns attributes), I do not completely > > > understand the purpose of this element. > > > > > > Could anyone explain the importance of the 'ns-binding' element? Isn't > > > it redundant? Why it doesn't suffice to extract namespace > abbreviations > > > from the xmlns attributes? > > > > > > Thanks, in advance. > > > > > > Regards, > > > > > > Michal Burda > > > > The subscriber is not typically aware nor need to be aware about the > used prefixes of published presence information. These prefixes are thus > used for XPath evaluations during filtering, i.e. expanding the names > within 'xpath' attribute values of and elements. One > could argue that it were simpler just to use in-scope namespaces of > those elements of filter document (just like in xml-patch-ops) but it is > only a matter of taste. As such they are certainly needed. Using > published presence document context here is not right. Still one option > is to use "namespace-uri()" and "local-name()" functions but it leads to > ugly looking and long rules. Default namespace is handled similarly to > XPath 1.0, i.e. a selector "foo" locates a unqualified element. >=20 > br, > Jari I think I was misunderstood. When I wrote "...xmlns attribute" above, I meant the attribute of the XML document contained in the body of the SUBSCRIBE request, not the presence document that is stored in presence server. In the speech of examples, my question was, why do we need to write: /pidf:presence/pidf:tuple/pidf:status/pidf:basic ...while we can equivalently write this: /pidf:presence/pidf:tuple/pidf:status/pidf:basic (please note the 'xmlns:pidf' attribute of the 'filter-set' element)...? In the latter example, we use standard XML feature of namespace bindings without the need to introduce a new element 'ns-bindings'. Regards, Michal _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 17 05:54:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKCbD-0001mq-Ni; Fri, 17 Mar 2006 05:54:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKCbC-0001ix-Ap for simple@ietf.org; Fri, 17 Mar 2006 05:54:26 -0500 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKCbB-0001rJ-Qt for simple@ietf.org; Fri, 17 Mar 2006 05:54:26 -0500 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] Issue with comparisons for triggerring Date: Fri, 17 Mar 2006 11:54:23 +0100 Message-ID: <31721CD4D0090B4BA32CBA5E2C40AE9001EFA6AB@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Issue with comparisons for triggerring Thread-Index: AcZJrgILIB16l8ENSoa1J0ggaqUknQAAJzdw From: To: X-OriginalArrivalTime: 17 Mar 2006 10:54:25.0186 (UTC) FILETIME=[27C46820:01C649B1] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: jari.urpalainen@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: , Errors-To: simple-bounces@ietf.org > -----Original Message----- > From: Jari Urpalainen [mailto:jari.urpalainen@nokia.com] > Sent: Friday, March 17, 2006 11:29 AM > To: ext Hisham Khartabil > Cc: Burda Michal; simple@ietf.org > Subject: Re: [Simple] Issue with comparisons for triggerring >=20 > On Thu, 2006-03-16 at 21:14 +0100, ext Hisham Khartabil wrote: > > Michal is correct in his observation. The NOTIFY at step 7 should not > > be sent. As far as the subscriber is concerned, the is C (receiving the > > NOTIFY at step 3). There is no new information given to the subscriber > > at step 7 that s/he requested. > > > > Hisham >=20 > ok, I was afraid that this wasn't unambiguous enough. So now I must > change my mind (after re-reading the format i-d) that the text needs > some clarification, i.e. it should say that the trigger rule is one-shot > only (perhaps I was mislead by correspondence with electronics, e.g. > monostable multivibrator ;-)). But I don't want to argue whether > multi-shot or one-shot behavior is better... >=20 > br, > Jari I can realize use-cases on that "multi-shot" trigger's rules, so IMHO "multi-shot" is better. Could anyone provide counter-examples to clarify, why the specification actually proposes the "one-shot" behaviour? Pros of "multi-shot" behaviour (actually not supported by specs) follow: 1. Use-case: a user wants to be notified whenever some particular presentity becomes "online". -- I can imagine an application that waits for some user's service to become available in order to perform some action etc. 2. The "Filtering & Throttling paradox" discussed few days ago won't occur at all. 3. No trigger criteria could cause to "logically terminate" a subscription - that is, there wouldn't occur the situation where the subscription exists but no notification is sent ever because of one-shot trigger that eats all of them. br, Michal _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 17 05:56:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKCdB-0001wy-Ap; Fri, 17 Mar 2006 05:56:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKCd9-0001wt-OE for simple@ietf.org; Fri, 17 Mar 2006 05:56:27 -0500 Received: from [130.94.222.106] (helo=citilindia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKCd8-0001uX-Di for simple@ietf.org; Fri, 17 Mar 2006 05:56:27 -0500 Received: (qmail 59583 invoked by uid 24170); 17 Mar 2006 10:56:25 -0000 Received: from unknown (HELO Abhijit) ([59.95.17.46]) (envelope-sender ) by 130.94.222.106 (qmail-ldap-1.03) with SMTP for ; 17 Mar 2006 10:56:25 -0000 Message-ID: From: "Abhijit A. Mahajani" To: Date: Fri, 17 Mar 2006 16:26:23 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4952.2800 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4952.2800 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Simple] What is the difference between SIP PUBLISH and SIP SUBSRIBE 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="===============0579646926==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0579646926== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C649DF.87D4E950" This is a multi-part message in MIME format. ------=_NextPart_000_0035_01C649DF.87D4E950 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi What is the difference between the following SIP Methods: PUBLISH and SUBSCRIBE? Is it mandatory to implement PUBLISH in presence implementation?=20 Thanks and REgards. Abhijit ------=_NextPart_000_0035_01C649DF.87D4E950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
What is the difference between the = following SIP=20 Methods:
PUBLISH and SUBSCRIBE?
Is it mandatory to implement PUBLISH in = presence=20 implementation?
Thanks and REgards.
Abhijit
------=_NextPart_000_0035_01C649DF.87D4E950-- --===============0579646926== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0579646926==-- From simple-bounces@ietf.org Fri Mar 17 06:06:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKCn6-00013i-GO; Fri, 17 Mar 2006 06:06:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKCn5-00013d-EC for simple@ietf.org; Fri, 17 Mar 2006 06:06:43 -0500 Received: from tidos.tid.es ([193.145.240.2] helo=correo.tid.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKCmz-0002QH-7r for simple@ietf.org; Fri, 17 Mar 2006 06:06:43 -0500 Received: from matrix2 ([10.95.73.36]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IW9006AJQURK0@tid.hi.inet> for simple@ietf.org; Fri, 17 Mar 2006 12:06:28 +0100 (MET) Date: Fri, 17 Mar 2006 12:06:28 +0100 From: =?iso-8859-1?Q?Gustavo_Garc=EDa_Bernardo?= Subject: RE: [Simple] What is the difference between SIP PUBLISH and SIP SUBSRIBE In-reply-to: To: "'Abhijit A. Mahajani'" , simple@ietf.org Message-id: <01b001c649b2$d7686ff0$2b02fea9@matrix2> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcZJsZOKqodl4PKuT3St83eHVrODswAACilQ X-Spam-Score: 0.1 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: 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="===============1854446927==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1854446927== Content-type: multipart/alternative; boundary="Boundary_(ID_esztXkRo0NNi5CA4Bw5cAA)" This is a multi-part message in MIME format. --Boundary_(ID_esztXkRo0NNi5CA4Bw5cAA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable PUBLISH method is for publishing your presence information =93I=92m = online=94 SUBSCRIBE method is for subscribing to the presence of other =93I want = to receive the presence of xxx=94 =20 If you have a centralized presence server (working as presence agent) = you need to implement PUBLISH if you want that your SIP UA could change his presence state using SIP. If you implement presence in a P2P way (as Windows Messenger do for example), you doesn=92t need to implement PUBLISH. But I think this P2P solution has limited features (at least as implemented in WM).=20 =20 Regards =20 _____ =20 De: Abhijit A. Mahajani [mailto:abhijit_m@citilindia.com]=20 Enviado el: viernes, 17 de marzo de 2006 11:56 Para: simple@ietf.org Asunto: [Simple] What is the difference between SIP PUBLISH and SIP = SUBSRIBE =20 Hi What is the difference between the following SIP Methods: PUBLISH and SUBSCRIBE? Is it mandatory to implement PUBLISH in presence implementation?=20 Thanks and REgards. Abhijit --Boundary_(ID_esztXkRo0NNi5CA4Bw5cAA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

PUBLISH method = is for publishing your presence information=A0 “I’m = online”

SUBSCRIBE method = is for subscribing to the presence of other=A0 “I want to receive the = presence of xxx”

 =

If you have a = centralized presence server (working as presence agent) you need to implement = PUBLISH if you want that your SIP UA could change his presence state using = SIP.

If you implement = presence in a P2P way (as Windows Messenger do for example), you doesn’t = need to implement PUBLISH.=A0 But I think this P2P solution has limited features = (at least as implemented in WM).

 =

Regards

 =

De: = Abhijit A. Mahajani [mailto:abhijit_m@citilindia.com]
Enviado el: viernes, 17 = de marzo de 2006 11:56
Para: simple@ietf.org
Asunto: [Simple] What is = the difference between SIP PUBLISH and SIP = SUBSRIBE

 

Hi

What is the difference between the following SIP = Methods:

PUBLISH and SUBSCRIBE?

Is it mandatory to implement PUBLISH in presence implementation?

Thanks and REgards.

Abhijit

--Boundary_(ID_esztXkRo0NNi5CA4Bw5cAA)-- --===============1854446927== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1854446927==-- From simple-bounces@ietf.org Fri Mar 17 06:12:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKCsx-0005p1-N9; Fri, 17 Mar 2006 06:12:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKCsv-0005or-Lt for simple@ietf.org; Fri, 17 Mar 2006 06:12:45 -0500 Received: from [130.94.222.106] (helo=citilindia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKCsv-0002bc-6I for simple@ietf.org; Fri, 17 Mar 2006 06:12:45 -0500 Received: (qmail 85884 invoked by uid 24170); 17 Mar 2006 11:12:43 -0000 Received: from unknown (HELO Abhijit) ([59.95.17.46]) (envelope-sender ) by 130.94.222.106 (qmail-ldap-1.03) with SMTP for ; 17 Mar 2006 11:12:43 -0000 Message-ID: From: "Abhijit A. Mahajani" To: References: <52db68bc0603170305p39210036g82fb299e3be3726f@mail.gmail.com> Subject: Re: [Simple] What is the difference between SIP PUBLISH and SIP SUBSRIBE Date: Fri, 17 Mar 2006 16:42:41 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4952.2800 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4952.2800 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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="===============1236710894==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1236710894== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0060_01C649E1.CF340540" This is a multi-part message in MIME format. ------=_NextPart_000_0060_01C649E1.CF340540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sudhir, Thanks. I perfectly agree. But if i have not implemented PUBLISH, still i SUBSCRIBE for some body, = then will i get any NOTIFICATION? in simple words: I am implementing Instant messaging and presence in my = SIP stack. Do I need to implemetn PUBLISH? is it mandatory? Regards. Abhijit ----- Original Message -----=20 From: Sudhir=20 To: Abhijit A. Mahajani=20 Sent: Friday, March 17, 2006 4:35 PM Subject: Re: [Simple] What is the difference between SIP PUBLISH and = SIP SUBSRIBE Hi Abhijit, The PUBLISH is used to publish ur presence status to the server. when = any user send SUBSCRIBE to know abt u ... the server send the status to = user which u send in the PUBLISH. i hope i'm clear. if not get badck to me \regards sudhir =20 On 3/17/06, Abhijit A. Mahajani wrote:=20 Hi What is the difference between the following SIP Methods: PUBLISH and SUBSCRIBE? Is it mandatory to implement PUBLISH in presence implementation?=20 Thanks and REgards. Abhijit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------=_NextPart_000_0060_01C649E1.CF340540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Sudhir,
Thanks. I perfectly agree.
But if i have not implemented PUBLISH, = still i=20 SUBSCRIBE for some body, then will i get any NOTIFICATION?
in simple words: I am implementing = Instant=20 messaging and presence in my SIP stack. Do I need to implemetn PUBLISH? = is it=20 mandatory?
 
Regards.
Abhijit
----- Original Message -----
From:=20 Sudhir
To: Abhijit=20 A. Mahajani
Sent: Friday, March 17, 2006 = 4:35=20 PM
Subject: Re: [Simple] What is = the=20 difference between SIP PUBLISH and SIP SUBSRIBE

Hi Abhijit,
 
The PUBLISH is used to publish ur presence status to = the server.=20 when any user send SUBSCRIBE to know abt u ... the server send the = status to=20 user which u send in the PUBLISH.
 
i hope i'm clear. if not get badck to me
\regards
sudhir

 
On 3/17/06, Abhijit A.=20 Mahajani <abhijit_m@citilindia.com>= =20 wrote:=20
Hi
What is the difference between the = following=20 SIP Methods:
PUBLISH and SUBSCRIBE?
Is it mandatory to implement = PUBLISH in=20 presence implementation?
Thanks and = REgards.
Abhijit

___________________________= ____________________
Simple=20 mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

=

------=_NextPart_000_0060_01C649E1.CF340540-- --===============1236710894== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1236710894==-- From simple-bounces@ietf.org Fri Mar 17 06:38:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKDHz-0003f9-Gu; Fri, 17 Mar 2006 06:38:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKDHy-0003f1-LZ for simple@ietf.org; Fri, 17 Mar 2006 06:38:38 -0500 Received: from smtpmast05.marconi.com ([128.87.251.114] helo=smtpmast05.marconi.com.) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKDHy-0003Bu-7M for simple@ietf.org; Fri, 17 Mar 2006 06:38:38 -0500 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpmast05.marconi.com. (8.12.11/8.12.11) with ESMTP id k2HAC6hU006937; Fri, 17 Mar 2006 11:38:36 GMT (envelope-from Sean.Leahy@marconi.com) To: "Jari Urpalainen Subject: Re: [Simple] Issue with comparisons for triggerring MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Sean Leahy" Date: Fri, 17 Mar 2006 11:08:50 +0000 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 17/03/2006 11:38:27, Serialize complete at 17/03/2006 11:38:27 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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: , Content-Type: multipart/mixed; boundary="===============0040976340==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============0040976340== Content-Type: multipart/alternative; boundary="=_alternative 003D3B9280257134_=" This is a multipart message in MIME format. --=_alternative 003D3B9280257134_= Content-Type: text/plain; charset="us-ascii" I think the filter is not a one shot in the sense that although it cannot shoot again as it is (because the required source state can never be reached since the watcher only sees the target state), the filter has to be maintained because it may be 'disabled' by the watcher and then 'enabled' again after a return to the required source state (whilst disabled). Is this your position - Hisham ? Sean Jari Urpalainen 17/03/2006 10:28 To: ext Hisham Khartabil cc: simple@ietf.org Subject: Re: [Simple] Issue with comparisons for triggerring On Thu, 2006-03-16 at 21:14 +0100, ext Hisham Khartabil wrote: > Michal is correct in his observation. The NOTIFY at step 7 should not > be sent. As far as the subscriber is concerned, the is C (receiving the > NOTIFY at step 3). There is no new information given to the subscriber > at step 7 that s/he requested. > > Hisham ok, I was afraid that this wasn't unambiguous enough. So now I must change my mind (after re-reading the format i-d) that the text needs some clarification, i.e. it should say that the trigger rule is one-shot only (perhaps I was mislead by correspondence with electronics, e.g. monostable multivibrator ;-)). But I don't want to argue whether multi-shot or one-shot behavior is better... br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --=_alternative 003D3B9280257134_= Content-Type: text/html; charset="us-ascii"
I think the filter is not a one shot in the sense that although it cannot shoot again as it is (because the required source state can never be reached since the watcher only sees the target state), the filter has to be maintained because it may be 'disabled' by the watcher and then 'enabled' again after a return to the required source state (whilst disabled).

Is this your position - Hisham ?

Sean



Jari Urpalainen <jari.urpalainen@nokia.com>

17/03/2006 10:28

       
        To:        ext Hisham Khartabil <hisham.khartabil@telio.no>
        cc:        simple@ietf.org
        Subject:        Re: [Simple] Issue with comparisons for triggerring



On Thu, 2006-03-16 at 21:14 +0100, ext Hisham Khartabil wrote:
> Michal is correct in his observation. The NOTIFY at step 7 should not
> be sent. As far as the subscriber is concerned, the is C (receiving the
> NOTIFY at step 3). There is no new information given to the subscriber
> at step 7 that s/he requested.
>
> Hisham

ok, I was afraid that this wasn't unambiguous enough. So now I must
change my mind (after re-reading the format i-d) that the text needs
some clarification, i.e. it should say that the trigger rule is one-shot
only (perhaps I was mislead by correspondence with electronics, e.g.
monostable multivibrator ;-)). But I don't want to argue whether
multi-shot or one-shot behavior is better...

br,
Jari


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

--=_alternative 003D3B9280257134_=-- --===============0040976340== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0040976340==-- From simple-bounces@ietf.org Fri Mar 17 07:33:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKE8b-0005e1-5r; Fri, 17 Mar 2006 07:33:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKE8Z-0005ds-NJ for simple@ietf.org; Fri, 17 Mar 2006 07:32:59 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKE8Y-0004pM-8R for simple@ietf.org; Fri, 17 Mar 2006 07:32:59 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2HCUnGT009700; Fri, 17 Mar 2006 14:30:51 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 14:32:50 +0200 Received: from [172.21.38.152] ([172.21.38.152]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 17 Mar 2006 14:32:50 +0200 Message-ID: <441AAC70.5070206@nokia.com> Date: Fri, 17 Mar 2006 14:32:48 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "ext Abhijit A. Mahajani" Subject: Re: [Simple] What is the difference between SIP PUBLISH and SIP SUBSRIBE References: <52db68bc0603170305p39210036g82fb299e3be3726f@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2006 12:32:50.0089 (UTC) FILETIME=[E75D1990:01C649BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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: , Errors-To: simple-bounces@ietf.org You only need PUBLISH, if there's a presence server that accepts publications. That server is probably the same entity that accepts subscriptions and sends notifications, too. I'd say you need to support PUBLISH. Cheers, Aki ext Abhijit A. Mahajani wrote: > Hi Sudhir, > Thanks. I perfectly agree. > But if i have not implemented PUBLISH, still i SUBSCRIBE for some body, > then will i get any NOTIFICATION? > in simple words: I am implementing Instant messaging and presence in my > SIP stack. Do I need to implemetn PUBLISH? is it mandatory? > > Regards. > Abhijit > > ----- Original Message ----- > *From:* Sudhir > *To:* Abhijit A. Mahajani > *Sent:* Friday, March 17, 2006 4:35 PM > *Subject:* Re: [Simple] What is the difference between SIP PUBLISH > and SIP SUBSRIBE > > Hi Abhijit, > > The PUBLISH is used to publish ur presence status to the server. > when any user send SUBSCRIBE to know abt u ... the server send the > status to user which u send in the PUBLISH. > > i hope i'm clear. if not get badck to me > \regards > sudhir > > > On 3/17/06, *Abhijit A. Mahajani* > wrote: > > Hi > What is the difference between the following SIP Methods: > PUBLISH and SUBSCRIBE? > Is it mandatory to implement PUBLISH in presence implementation? > Thanks and REgards. > Abhijit > > _______________________________________________ > 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 Mar 17 07:56:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKEUy-0006qx-Nh; Fri, 17 Mar 2006 07:56:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKEUw-0006qU-OV for simple@ietf.org; Fri, 17 Mar 2006 07:56:07 -0500 Received: from web52803.mail.yahoo.com ([206.190.48.246]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FKEUv-0005Qq-Gf for simple@ietf.org; Fri, 17 Mar 2006 07:56:06 -0500 Received: (qmail 28368 invoked by uid 60001); 17 Mar 2006 12:56:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ojhacpprjdAqoLs0ZE3d3O114USkpZOCE+ccEORWL1PrFfF1a/buY5mqisQzQscvlY+yPljnH2tdgsbh//YXpGiLz4JiDtl9BpB8S811S/pKGHu9cy3050+HAtZl7fLqyXCVeuKq2ecUl/HPdMleRePgEVuz49nmTQdQHSDlfhs= ; Message-ID: <20060317125601.28366.qmail@web52803.mail.yahoo.com> Received: from [47.165.147.102] by web52803.mail.yahoo.com via HTTP; Fri, 17 Mar 2006 04:56:01 PST Date: Fri, 17 Mar 2006 04:56:01 -0800 (PST) From: Fatih "Eyüp" NAR To: simple@ietf.org, sip@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Simple] whose preference comes first:RFC 3841 or Terminator's CPL 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: , Errors-To: simple-bounces@ietf.org Hi; I am trying to identify; "what Proxy Shall do in case received session included Originator's Preference (ex:Request-Disposition=No-Fork) inside and Proxy also has Terminator's CPL Rules (ex:it says Fork to call to Home-Office-Mobile at the same time) ? I couln't see any explanation (i.e. RFC) about that till now anywhere , can you help me on this please? regards fatih e. nar __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 17 08:01:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKEaW-0003Yi-0C; Fri, 17 Mar 2006 08:01:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKEaR-0003KU-Td for simple@ietf.org; Fri, 17 Mar 2006 08:01:48 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKEaR-0005kb-CS for simple@ietf.org; Fri, 17 Mar 2006 08:01:47 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2HD1ivG012050; Fri, 17 Mar 2006 15:01:46 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 15:01:38 +0200 Received: from mgw-int1.ntc.nokia.com ([172.21.143.96]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 17 Mar 2006 15:01:37 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2HD1a128718; Fri, 17 Mar 2006 15:01:37 +0200 (EET) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by kusti.research.nokia.com (Postfix) with ESMTP id DCE2D93B75; Fri, 17 Mar 2006 15:01:36 +0200 (EET) Subject: RE: [Simple] Filtering: the purpose of the 'ns-binding' element From: Jari Urpalainen To: "ext Michal.Burda@tietoenator.com" In-Reply-To: <31721CD4D0090B4BA32CBA5E2C40AE9001EFA67A@carrera.eu.tieto.com> References: <31721CD4D0090B4BA32CBA5E2C40AE9001EFA67A@carrera.eu.tieto.com> Content-Type: text/plain Date: Fri, 17 Mar 2006 15:01:36 +0200 Message-Id: <1142600496.3697.68.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2006 13:01:37.0960 (UTC) FILETIME=[ED414A80:01C649C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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: , Errors-To: simple-bounces@ietf.org On Fri, 2006-03-17 at 11:32 +0100, ext Michal.Burda@tietoenator.com wrote: > > > -----Original Message----- > > From: Jari Urpalainen [mailto:jari.urpalainen@nokia.com] > > Sent: Friday, March 17, 2006 11:09 AM > > To: ext Thomson, Martin > > Cc: Burda Michal; simple@ietf.org > > Subject: RE: [Simple] Filtering: the purpose of the 'ns-binding' > element > > > > On Wed, 2006-03-15 at 15:06 -0600, ext Thomson, Martin wrote: > > > I think that it is not only redundant, but dangerous. It is > possible to > > have contradictory values in there and in the xmlns:... attributes. I > > can't think of a good reason to include such an element in this > context. > > > > > > > -----Original Message----- > > > > From: Michal.Burda@tietoenator.com > > [mailto:Michal.Burda@tietoenator.com] > > > > Sent: Wednesday, 15 March 2006 9:25 PM > > > > To: simple@ietf.org > > > > Subject: [Simple] Filtering: the purpose of the 'ns-binding' > element > > > > > > > > Hi, > > > > > > > > each filter-set document may contain the 'ns-binding' element. > > > > Considering that the XML document itself has the means of defining > > > > namespace abbreviations (xmlns attributes), I do not completely > > > > understand the purpose of this element. > > > > > > > > Could anyone explain the importance of the 'ns-binding' element? > Isn't > > > > it redundant? Why it doesn't suffice to extract namespace > > abbreviations > > > > from the xmlns attributes? > > > > > > > > Thanks, in advance. > > > > > > > > Regards, > > > > > > > > Michal Burda > > > > > > The subscriber is not typically aware nor need to be aware about the > > used prefixes of published presence information. These prefixes are > thus > > used for XPath evaluations during filtering, i.e. expanding the names > > within 'xpath' attribute values of and elements. > One > > could argue that it were simpler just to use in-scope namespaces of > > those elements of filter document (just like in xml-patch-ops) but it > is > > only a matter of taste. As such they are certainly needed. Using > > published presence document context here is not right. Still one > option > > is to use "namespace-uri()" and "local-name()" functions but it leads > to > > ugly looking and long rules. Default namespace is handled similarly to > > XPath 1.0, i.e. a selector "foo" locates a unqualified element. > > > > br, > > Jari > > > I think I was misunderstood. When I wrote "...xmlns attribute" above, I > meant the attribute of the XML document contained in the body of the > SUBSCRIBE request, not the presence document that is stored in presence > server. > ok, sorry, my false interpretation. > In the speech of examples, my question was, why do we need to write: > > > > > > > > > /pidf:presence/pidf:tuple/pidf:status/pidf:basic > > > > > > ...while we can equivalently write this: > > xmlns:pidf="urn:ietf:params:xml:ns:pidf"> > > > > /pidf:presence/pidf:tuple/pidf:status/pidf:basic > > > > > > (please note the 'xmlns:pidf' attribute of the 'filter-set' element)...? > > In the latter example, we use standard XML feature of namespace bindings > without the need to introduce a new element 'ns-bindings'. > > > Regards, > > Michal > Certainly I'd prefer using in-scope namespaces (because they are cleaner, filter documents were shorter etc.). However, this means quite many changes to these i-d's and the current aren't buggy, i.e. they do work although they don't look nice. Also this new format should then specify how default namespaces are handled, similar to xml-patch-ops, XCAP, XPath 1.0 or XPath 2.0 ?, and this means once again, some more text (and probably some dispute on the model chosen). br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 17 08:59:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKFUW-0007pM-4u; Fri, 17 Mar 2006 08:59:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKFUU-0007pH-Tj for simple@ietf.org; Fri, 17 Mar 2006 08:59:42 -0500 Received: from mail.cis.nctu.edu.tw ([140.113.23.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKFUT-0007lA-BB for simple@ietf.org; Fri, 17 Mar 2006 08:59:42 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.cis.nctu.edu.tw (8.13.4/8.13.4) with ESMTP id k2HDxb2a019232 for ; Fri, 17 Mar 2006 21:59:37 +0800 (CST) (envelope-from icq.cis92@gmail.com) Received: from mail.cis.nctu.edu.tw ([127.0.0.1]) by localhost (mail.cis.nctu.edu.tw [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 85927-23 for ; Fri, 17 Mar 2006 21:59:37 +0800 (CST) Received: from [140.113.139.53] (icq.Dorm13.NCTU.edu.tw [140.113.139.53]) (authenticated bits=0 as is92066 with PLAIN) by mail.cis.nctu.edu.tw (8.13.4/8.13.4) with ESMTP id k2HDxau0019190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Mar 2006 21:59:36 +0800 (CST) (envelope-from icq.cis92@gmail.com) Message-ID: <441AC0C7.4080700@gmail.com> Date: Fri, 17 Mar 2006 21:59:35 +0800 From: Ren-Huang Liou User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: zh-tw, en-us, en MIME-Version: 1.0 To: simple@ietf.org Subject: [Simple]Question on XCAP Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at cis.nctu.edu.tw X-Spam-Score: 0.5 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: simple-bounces@ietf.org Hi, Why do the SIMPLE working group use XCAP to read, write and modify application configuration on a server? Why don't they develop another SIP request to do the same thing as XCAP? When using XCAP, I need to set up a http server. Is it really worth handling buddies list by another protocol (XCAP over HTTP)? Thanks in advance Best regards, Ren-Huang Liou _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 17 09:23:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKFrV-0006rH-Te; Fri, 17 Mar 2006 09:23:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKFrU-0006Yj-5c for simple@ietf.org; Fri, 17 Mar 2006 09:23:28 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKFrS-0000HP-Ql for simple@ietf.org; Fri, 17 Mar 2006 09:23:28 -0500 Received: from [192.168.1.105] (c-24-1-44-191.hsd1.tx.comcast.net [24.1.44.191]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.3) with ESMTP id k2HENOTj012351 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 17 Mar 2006 08:23:25 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: References: <52db68bc0603170305p39210036g82fb299e3be3726f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <699BED1C-124A-4F41-9D96-B310F72DC9BA@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] What is the difference between SIP PUBLISH and SIP SUBSRIBE Date: Fri, 17 Mar 2006 08:23:17 -0600 To: "Abhijit A. Mahajani" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 1.1 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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: , Errors-To: simple-bounces@ietf.org To be clear, there is no specification that says you "MUST" implement PUBLISH to do presence. It really comes down to an architectural decision. If you want presentities to be able to push their presence information to a central presence server, you need PUBLISH. If you want to build a server or client that interoperates with other servers and/or clients, then PUBLISH is certainly a good idea. But PUBLISH is not explicitly needed to make SUBSCRIBE work. You can have a device that consumes presence, but does not publish it--in which case that device would not need to implement PUBLISH. On Mar 17, 2006, at 5:12 AM, Abhijit A. Mahajani wrote: > Hi Sudhir, > Thanks. I perfectly agree. > But if i have not implemented PUBLISH, still i SUBSCRIBE for some > body, then will i get any NOTIFICATION? > in simple words: I am implementing Instant messaging and presence > in my SIP stack. Do I need to implemetn PUBLISH? is it mandatory? > > Regards. > Abhijit > ----- Original Message ----- > From: Sudhir > To: Abhijit A. Mahajani > Sent: Friday, March 17, 2006 4:35 PM > Subject: Re: [Simple] What is the difference between SIP PUBLISH > and SIP SUBSRIBE > > Hi Abhijit, > > The PUBLISH is used to publish ur presence status to the server. > when any user send SUBSCRIBE to know abt u ... the server send the > status to user which u send in the PUBLISH. > > i hope i'm clear. if not get badck to me > \regards > sudhir > > > On 3/17/06, Abhijit A. Mahajani wrote: > Hi > What is the difference between the following SIP Methods: > PUBLISH and SUBSCRIBE? > Is it mandatory to implement PUBLISH in presence implementation? > Thanks and REgards. > Abhijit > > _______________________________________________ > 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 Mar 17 11:17:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKHe7-0008HF-18; Fri, 17 Mar 2006 11:17:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKHe6-0008HA-0C for simple@ietf.org; Fri, 17 Mar 2006 11:17:46 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKHe4-0004Ee-OY for simple@ietf.org; Fri, 17 Mar 2006 11:17:45 -0500 Received: from [142.131.190.76] ([142.131.190.76]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2HGHh3Z080768 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 17 Mar 2006 10:17:44 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v746.2) References: <533A3A79-CCB2-4F65-A2D5-2C09EA3C0ED9@estacado.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C05128B-12CD-403B-89E7-821CB413C1D0@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Fri, 17 Mar 2006 08:17:40 -0800 To: "simple@ietf.org list" X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 142.131.190.76 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Simple] Design team: meeting the remaining IM requirements 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: , Errors-To: simple-bounces@ietf.org Folks - Part of our remaining work (as we will discuss in Dallas) is meeting the remainder of the advanced instant messaging requirements. This includes the IMDN work we are currently engaged in. In order to put some pressure on this set of topics, we are going to repurpose the IMDN time in the SIMPLE meeting to touch base on the requirements document and the outstanding work needed to satisfy it. We'll then pull together a design team to finish these off. This team's first action will be to conclude on the last outstanding issues in the IMDN conversation (one major goal here is to get more than Hisham and Eric re-engaged in the discussion). We are tentatively scheduling this design team meeting for the Thursday Afternoon II session. If you plan to participate, RSVP directly to me. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 17 14:21:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKVT-0007QZ-Hf; Fri, 17 Mar 2006 14:21:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKVS-0007QU-HI for simple@ietf.org; Fri, 17 Mar 2006 14:21:02 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKKVP-0002PK-RS for simple@ietf.org; Fri, 17 Mar 2006 14:21:02 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 8FB85194454 for ; Fri, 17 Mar 2006 20:20:58 +0100 (CET) Received: from [10.75.117.242] ([216.1.176.230]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 20:19:18 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <24dff549ee21059d4a3f095685365b07@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Simple] Issue with comparisons for triggerring Date: Fri, 17 Mar 2006 20:21:29 +0100 To: "Sean Leahy" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 17 Mar 2006 19:19:18.0979 (UTC) FILETIME=[B0466130:01C649F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: "Jari Urpalainen , 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: , Errors-To: simple-bounces@ietf.org In this example, it was one shot, but other use cases will show it can=20= be multi shot. It all depends on the filter. A general =20 triggering filter, for example is hardly one shot. And yes, you can disable then enable filters, but that doesnt make it=20 multi shot. Hisham On Mar 17, 2006, at 12:08 PM, Sean Leahy wrote: > > I think the filter is not a one shot in the sense that although it=20 > cannot shoot again as it is (because the required source state can=20 > never be reached since the watcher only sees the target state), the=20 > filter has to be maintained because it may be 'disabled' by the=20 > watcher and then 'enabled' again after a return to the required source=20= > state (whilst disabled). > > Is this your position - Hisham ? > > Sean > > > > Jari Urpalainen > > 17/03/2006 10:28 > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0ext Hisham Khartabil = > =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0simple@ietf.org > =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0Re: [Simple] Issue with = comparisons for=20 > triggerring > > > > On Thu, 2006-03-16 at 21:14 +0100, ext Hisham Khartabil wrote: > > Michal is correct in his observation. The NOTIFY at step 7 should=20= > not > > be sent. As far as the subscriber is concerned, the is C (receiving=20= > the > > NOTIFY at step 3). There is no new information given to the=20 > subscriber > > at step 7 that s/he requested. > > > > Hisham > > ok, I was afraid that this wasn't unambiguous enough. So now I must > change my mind (after re-reading the format i-d) that the text needs > some clarification, i.e. it should say that the trigger rule is=20 > one-shot > only (perhaps I was mislead by correspondence with electronics, e.g. > monostable multivibrator ;-)). But I don't want to argue whether > multi-shot or one-shot behavior is better... > > br, > Jari > > > _______________________________________________ > 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 Mar 17 14:30:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKeT-0003Ho-Ns; Fri, 17 Mar 2006 14:30:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKeS-0003Hj-AS for simple@ietf.org; Fri, 17 Mar 2006 14:30:20 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKKeR-0002Wh-Oo for simple@ietf.org; Fri, 17 Mar 2006 14:30:20 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 281ED194482 for ; Fri, 17 Mar 2006 20:30:19 +0100 (CET) Received: from [10.75.117.242] ([216.1.176.230]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 20:28:38 +0100 In-Reply-To: <1142600496.3697.68.camel@hed034-145.research.nokia.com> References: <31721CD4D0090B4BA32CBA5E2C40AE9001EFA67A@carrera.eu.tieto.com> <1142600496.3697.68.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <213324b0875465c2faf0696868e2489b@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Filtering: the purpose of the 'ns-binding' element Date: Fri, 17 Mar 2006 20:30:44 +0100 To: Jari Urpalainen X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 17 Mar 2006 19:28:38.0907 (UTC) FILETIME=[FE049CB0:01C649F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: extMichal.Burda@tietoenator.com, simple@ietf.orgWG, 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: , Errors-To: simple-bounces@ietf.org Jari, your first response was correct. I don't what you are talking about in this response :) Michal, you have misinterpretted the ns-binding. You cannot use the in-scope namespace to be used in the element. It has a value of string. Well, you can, but its ugly and confusing. Typically namespaces are used for the XML document element themselves and not for the values on the xml elements that just happened to have xpath expressions. Hisham On Mar 17, 2006, at 2:01 PM, Jari Urpalainen wrote: > On Fri, 2006-03-17 at 11:32 +0100, ext Michal.Burda@tietoenator.com > wrote: >> >>> -----Original Message----- >>> From: Jari Urpalainen [mailto:jari.urpalainen@nokia.com] >>> Sent: Friday, March 17, 2006 11:09 AM >>> To: ext Thomson, Martin >>> Cc: Burda Michal; simple@ietf.org >>> Subject: RE: [Simple] Filtering: the purpose of the 'ns-binding' >> element >>> >>> On Wed, 2006-03-15 at 15:06 -0600, ext Thomson, Martin wrote: >>>> I think that it is not only redundant, but dangerous. It is >> possible to >>> have contradictory values in there and in the xmlns:... attributes. >>> I >>> can't think of a good reason to include such an element in this >> context. >>>> >>>>> -----Original Message----- >>>>> From: Michal.Burda@tietoenator.com >>> [mailto:Michal.Burda@tietoenator.com] >>>>> Sent: Wednesday, 15 March 2006 9:25 PM >>>>> To: simple@ietf.org >>>>> Subject: [Simple] Filtering: the purpose of the 'ns-binding' >> element >>>>> >>>>> Hi, >>>>> >>>>> each filter-set document may contain the 'ns-binding' element. >>>>> Considering that the XML document itself has the means of defining >>>>> namespace abbreviations (xmlns attributes), I do not completely >>>>> understand the purpose of this element. >>>>> >>>>> Could anyone explain the importance of the 'ns-binding' element? >> Isn't >>>>> it redundant? Why it doesn't suffice to extract namespace >>> abbreviations >>>>> from the xmlns attributes? >>>>> >>>>> Thanks, in advance. >>>>> >>>>> Regards, >>>>> >>>>> Michal Burda >>>>> >>> The subscriber is not typically aware nor need to be aware about the >>> used prefixes of published presence information. These prefixes are >> thus >>> used for XPath evaluations during filtering, i.e. expanding the names >>> within 'xpath' attribute values of and elements. >> One >>> could argue that it were simpler just to use in-scope namespaces of >>> those elements of filter document (just like in xml-patch-ops) but it >> is >>> only a matter of taste. As such they are certainly needed. Using >>> published presence document context here is not right. Still one >> option >>> is to use "namespace-uri()" and "local-name()" functions but it leads >> to >>> ugly looking and long rules. Default namespace is handled similarly >>> to >>> XPath 1.0, i.e. a selector "foo" locates a unqualified element. >>> >>> br, >>> Jari >> >> >> I think I was misunderstood. When I wrote "...xmlns attribute" above, >> I >> meant the attribute of the XML document contained in the body of the >> SUBSCRIBE request, not the presence document that is stored in >> presence >> server. >> > ok, sorry, my false interpretation. > >> In the speech of examples, my question was, why do we need to write: >> >> >> >> >> >> >> >> >> /pidf:presence/pidf:tuple/pidf:status/pidf:basic >> >> >> >> >> >> ...while we can equivalently write this: >> >> > xmlns:pidf="urn:ietf:params:xml:ns:pidf"> >> >> >> >> /pidf:presence/pidf:tuple/pidf:status/pidf:basic >> >> >> >> >> >> (please note the 'xmlns:pidf' attribute of the 'filter-set' >> element)...? >> >> In the latter example, we use standard XML feature of namespace >> bindings >> without the need to introduce a new element 'ns-bindings'. >> >> >> Regards, >> >> Michal >> > Certainly I'd prefer using in-scope namespaces (because they are > cleaner, filter documents were shorter etc.). However, this means quite > many changes to these i-d's and the current aren't buggy, > i.e. they do work although they don't look nice. Also this new format > should then specify how default namespaces are handled, similar to > xml-patch-ops, XCAP, XPath 1.0 or XPath 2.0 ?, and this means once > again, some more text (and probably some dispute on the model chosen). > br, > Jari > > > > > _______________________________________________ > 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 Sat Mar 18 13:14:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKfw1-000742-Ss; Sat, 18 Mar 2006 13:13:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKfw0-00073x-Ma for simple@ietf.org; Sat, 18 Mar 2006 13:13:52 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKfvz-00026s-Dt for simple@ietf.org; Sat, 18 Mar 2006 13:13:52 -0500 Received: from [192.168.0.105] (pool-70-104-24-164.dllstx.fios.verizon.net [70.104.24.164]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2IIDn2r081826 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 18 Mar 2006 12:13:50 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Sat, 18 Mar 2006 12:13:52 -0600 To: "simple@ietf.org list" X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 70.104.24.164 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Simple] Agenda update 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: , Errors-To: simple-bounces@ietf.org I've updated the posted agenda for the SIMPLE meeting, reflecting a shift in the time to discuss simple-chat (Aki has a conflict with the second half of the meeting), the adjustment on meeting the advanced IM requirements, and adding draft links. See http://www3.ietf.org/proceedings/06mar/ agenda/simple.html RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 18 14:59:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKha5-0003fg-0u; Sat, 18 Mar 2006 14:59:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKha3-0003ev-Nf; Sat, 18 Mar 2006 14:59:19 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKha2-0005Jt-Cq; Sat, 18 Mar 2006 14:59:19 -0500 Received: from [192.168.0.105] (pool-70-104-24-164.dllstx.fios.verizon.net [70.104.24.164]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2IJxEDw087463 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 18 Mar 2006 13:59:14 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <0B23EA50-279C-4548-B7F1-4CB334ABF93E@nostrum.com> References: <0B23EA50-279C-4548-B7F1-4CB334ABF93E@nostrum.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Sat, 18 Mar 2006 13:59:16 -0600 To: Robert Sparks X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 70.104.24.164 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "sip@ietf.org WG" , sip-implementors@cs.columbia.edu, Sipping WG , "simple@ietf.org list" Subject: [Simple] SIPit 18 Registration closes in 2 weeks 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: , Errors-To: simple-bounces@ietf.org Registration for SIPit 18 closes March 31 (13 days from now). If you are planning to attend, but have not already registered, please register now. Thanks, RjS On Feb 6, 2006, at 11:42 PM, Robert Sparks wrote: > Registration for SIPit 18 is open. > > This event will be held April 17-21 in > Akihabara, Tokyo, Japan. More information > about the event is available at http://www.sipit.net > and the host website at http://www.nic.ad.jp/en/sipit18/ > > Registration will close March 31. Please register early. > You can register now using https://www.regonline.com/88905 > > This 18th SIPForum SIPit is > > Hosted by: > - Japan Network Information Center (JPNIC) > > Co-hosted by: > - WIDE Project > - VoIP System Interoperability Task Force > > Supported by: > - Ministry of Internal Affairs and Communications (MIC) > - The Telecommunication Technology Committee (TTC) > - Telecom Service Association (TELESA) > - VoIP Forum Japan (VFJ) > - IPv6 Promotion Council (v6PC) > - ENUM Trial Japan (ETJP) > > Sponsors: > - Cisco Systems, Inc. > - Fractalist Inc. > - Fusion Communications Corporation > - Japan Telecom Co., Ltd. > - KDDI Corporation > - Mitsubishi Electric Information Network Corporation > - Mitsubishi Research Institute, Inc. > - NEC Corporation > - Netmarks Inc. > - Nippon Telegraph and Telephone Corporation > - Nippon Telegraph and Telephone East Corporation > - Nippon Telegraph and Telephone West Corporation > - NTT Advanced Technology Corporation > - Oki Electric Industry Co., Ltd. > - SoftBank BB Corp. > - Softfront > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Mar 18 19:37:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKlue-0005ao-Ae; Sat, 18 Mar 2006 19:36:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKlud-0005aj-I6 for simple@ietf.org; Sat, 18 Mar 2006 19:36:51 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKlud-0005un-8v for simple@ietf.org; Sat, 18 Mar 2006 19:36:51 -0500 Received: from [192.168.0.111] (ppp-70-249-144-46.dsl.rcsntx.swbell.net [70.249.144.46]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2J0anPd003019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Mar 2006 18:36:50 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <441CA79C.4000708@nostrum.com> Date: Sat, 18 Mar 2006 18:36:44 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt References: <43F07211.9040107@nokia.com> In-Reply-To: <43F07211.9040107@nokia.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.144.46 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: "'simple@ietf.org'" , Niemi Aki 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: , Errors-To: simple-bounces@ietf.org Miguel Garcia wrote: > We have just submitted a new version of the MSRP CHAT draft. This has > changed substantially from earlier versions, so I wouldn't dare to > summarize the changes. ----- By and large, this is far more palatable than previous versions. I'm still a little apprehensive about the fact that we will ultimately end up with more than one way to send messages to a subset of participants (either using the "To" CPIM field *or* using the conference control protocol), but I have convinced myself that these mechanisms can probably coexist with minimal pain. Time permitting, I'll put together some suggested text for your document that talks (in general terms) about how these mechanisms can interact with each other in a sane fashion. ----- I *do* have some of the same reservations as Paul does about nicknames. As has been brought up repeatedly: nicknames are most emphatically not an IM-only issue. The representation of conference participants is an extremely generalizable problem, and I can't as easily see how to harmonize two different mechanisms. In other words, the nickname reservation protocol that you're defining with the NICKNAME mechanism in MSRP shouldn't be limited to MSRP. My suggestion, for what it's worth, is that you (1) split the nickname reservation mechanism out into a separate draft, and (2) use either SIP or the XCON Conference Control Protocol instead of MSRP. ----- As a minor additional issue: one of the fundamental precepts of the conferencing framework (even pre-XCON) was that non-conference-aware participants should be able to participate in conferences, albeit with less control of the conference itself. To that end, it would probably be beneficial to indicate how participants who don't have CPIM clients will work. I think there are sensible ways of addressing this (e.g. if such a user sends a message, then the MSRP mixer adds a CPIM envelope that includes the user's identity, as learned during session establishment) -- they should probably be called out so that implementors of MSRP mixers will have some guidance around how they should behave.. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Mar 19 16:54:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL5qk-0003BK-3Z; Sun, 19 Mar 2006 16:54:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL5qi-0003BF-LJ for simple@ietf.org; Sun, 19 Mar 2006 16:54:08 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL5qh-0003zx-Ce for simple@ietf.org; Sun, 19 Mar 2006 16:54:08 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Mar 2006 13:54:08 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,109,1141632000"; d="scan'208"; a="23954443:sNHT23209932" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2JLs5Wc026289 for ; Sun, 19 Mar 2006 16:54:05 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Mar 2006 16:54:05 -0500 Received: from [130.129.128.208] ([10.86.242.53]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Mar 2006 16:54:05 -0500 Message-ID: <441DD2FE.8030809@cisco.com> Date: Sun, 19 Mar 2006 16:54:06 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 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-OriginalArrivalTime: 19 Mar 2006 21:54:05.0534 (UTC) FILETIME=[A451B7E0:01C64B9F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [Simple] XCAP specification: status and changes 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: , Errors-To: simple-bounces@ietf.org So, folks may have noticed that an updated XCAP document was never announced by the I-D editor. This was because, unfortunately, a revision didn't get done in time for the deadline. However, I was able to complete an update of the document after the deadline. The document is now available at my website: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-09.txt The changes reflect bug fixes and the main change we had agreed upon on the list - adding the ability to do conditional inserts. The full set of diffs are as follows: * Major change is allowing for insert operations to be conditional, so that an If-Match header field can be included. Furthermore, Etag is included in DELETE response. This allows for the xcap-diff document to be eliminated. * Terminology change: "path separator" to "node selector separator" since path separator seems like it would be a '/'. * clarification of algorithms for determining position of insertion, including many examples * Update ABNF reference to 4234 * Selection by name is now called selection by expanded name, since it is in fact the expanded name that is being used in the selection process * Grammar for node selector only allowed double quote around attributes previously; xpath allows single as well, so support for single quote is added * Selection extension had a bug - it only allowed a single character. Now it allows more than one. * Terminology change; escape-coded to percent encoded * clarify that "document context" is root node in XML terms * default namespace binding for the query string in the URI is definde by the application usage. The spec now says that, if undefined by the usage, its null * updated XPath 2.0 reference to most recent document * added to various example documents * fixed fairly major bug, which was quoting the URI in xmlns() expressions, and thus escaping them when placed into URI. These are not supposed to be quoted and thus there is no need for escaping. * xcap-error document was missing any possibility of extensibility. This was addressed by allowing an element. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Mar 19 17:28:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6Nw-00021k-L6; Sun, 19 Mar 2006 17:28:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6Nv-00021f-27 for simple@ietf.org; Sun, 19 Mar 2006 17:28:27 -0500 Received: from [207.14.217.166] (helo=server) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL6Nu-0005rK-CF for simple@ietf.org; Sun, 19 Mar 2006 17:28:26 -0500 Received: from [204.96.114.213] ([204.96.114.213]) by server (8.12.8/8.12.8) with SMTP id k2JL1O2x031817; Sun, 19 Mar 2006 16:01:26 -0500 In-Reply-To: <441CA79C.4000708@nostrum.com> References: <43F07211.9040107@nokia.com> <441CA79C.4000708@nostrum.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <39aa024240605fefdbf798e662c5dd0b@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt Date: Sun, 19 Mar 2006 23:28:55 +0100 To: Adam Roach X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Miguel Garcia , "'simple@ietf.org'" , Niemi Aki 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: , Errors-To: simple-bounces@ietf.org Speaking of nicknames. I don't understand why we need the MSRP extension NICKNAME to reserve a nickname for a chatroom. One would think that the nickname was reserved when the user joined the chatroom using the SIP From header field. Thanks, Hisham On Mar 19, 2006, at 1:36 AM, Adam Roach wrote: > Miguel Garcia wrote: > >> We have just submitted a new version of the MSRP CHAT draft. This has >> changed substantially from earlier versions, so I wouldn't dare to >> summarize the changes. > > ----- > > By and large, this is far more palatable than previous versions. I'm > still a little apprehensive about the fact that we will ultimately end > up with more than one way to send messages to a subset of participants > (either using the "To" CPIM field *or* using the conference control > protocol), but I have convinced myself that these mechanisms can > probably coexist with minimal pain. Time permitting, I'll put together > some suggested text for your document that talks (in general terms) > about how these mechanisms can interact with each other in a sane > fashion. > > ----- > > I *do* have some of the same reservations as Paul does about nicknames. > > As has been brought up repeatedly: nicknames are most emphatically not > an IM-only issue. The representation of conference participants is an > extremely generalizable problem, and I can't as easily see how to > harmonize two different mechanisms. > > In other words, the nickname reservation protocol that you're defining > with the NICKNAME mechanism in MSRP shouldn't be limited to MSRP. My > suggestion, for what it's worth, is that you (1) split the nickname > reservation mechanism out into a separate draft, and (2) use either > SIP or the XCON Conference Control Protocol instead of MSRP. > > ----- > > As a minor additional issue: one of the fundamental precepts of the > conferencing framework (even pre-XCON) was that non-conference-aware > participants should be able to participate in conferences, albeit with > less control of the conference itself. To that end, it would probably > be beneficial to indicate how participants who don't have CPIM clients > will work. > > I think there are sensible ways of addressing this (e.g. if such a > user sends a message, then the MSRP mixer adds a CPIM envelope that > includes the user's identity, as learned during session establishment) > -- they should probably be called out so that implementors of MSRP > mixers will have some guidance around how they should behave.. > > /a > > _______________________________________________ > 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 Sun Mar 19 17:32:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6Rq-0003Xk-TG; Sun, 19 Mar 2006 17:32:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6Ro-0003Xf-BA for simple@ietf.org; Sun, 19 Mar 2006 17:32:28 -0500 Received: from [207.14.217.166] (helo=server) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL6Rn-000609-Vb for simple@ietf.org; Sun, 19 Mar 2006 17:32:28 -0500 Received: from [204.96.114.213] ([204.96.114.213]) by server (8.12.8/8.12.8) with SMTP id k2JL5S2x031836 for ; Sun, 19 Mar 2006 16:05:29 -0500 Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: "'simple@ietf.org' WG" From: Hisham Khartabil Date: Sun, 19 Mar 2006 23:32:42 +0100 X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Simple] 'chatroom' SDP Attribute in simple-chat 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: , Errors-To: simple-bounces@ietf.org I'm not convinced that this is the correct way to learn about the chatroom/conference capabilities. I would think this is out of scope of this draft. Learning conference room capabilities is definitely not in scope here. Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Mar 19 17:37:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6Wf-00081y-Gr; Sun, 19 Mar 2006 17:37:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6We-00081t-Gl for simple@ietf.org; Sun, 19 Mar 2006 17:37:28 -0500 Received: from [207.14.217.166] (helo=server) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL6We-00063d-0t for simple@ietf.org; Sun, 19 Mar 2006 17:37:28 -0500 Received: from [204.96.114.213] ([204.96.114.213]) by server (8.12.8/8.12.8) with SMTP id k2JLAN2x031846; Sun, 19 Mar 2006 16:10:29 -0500 In-Reply-To: <39aa024240605fefdbf798e662c5dd0b@telio.no> References: <43F07211.9040107@nokia.com> <441CA79C.4000708@nostrum.com> <39aa024240605fefdbf798e662c5dd0b@telio.no> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5adc47eec39ea19ff23120ef0c1d67c9@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt Date: Sun, 19 Mar 2006 23:37:54 +0100 To: "'simple@ietf.org' WG" X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Miguel Garcia , Adam Roach , Niemi Aki 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: , Errors-To: simple-bounces@ietf.org And one other thing about nicknames :) This might be a matter of taste. Would a URI parameter be more appropriate. I.e. Instead of this sip:nordicguy%40room34@example.com you have this sip:room34@example.com;nickname="nordicguy" Thanks, Hisham On Mar 19, 2006, at 11:28 PM, Hisham Khartabil wrote: > Speaking of nicknames. I don't understand why we need the MSRP > extension NICKNAME to reserve a nickname for a chatroom. One would > think that the nickname was reserved when the user joined the chatroom > using the SIP From header field. > > Thanks, > Hisham > > On Mar 19, 2006, at 1:36 AM, Adam Roach wrote: > >> Miguel Garcia wrote: >> >>> We have just submitted a new version of the MSRP CHAT draft. This >>> has changed substantially from earlier versions, so I wouldn't dare >>> to summarize the changes. >> >> ----- >> >> By and large, this is far more palatable than previous versions. I'm >> still a little apprehensive about the fact that we will ultimately >> end up with more than one way to send messages to a subset of >> participants (either using the "To" CPIM field *or* using the >> conference control protocol), but I have convinced myself that these >> mechanisms can probably coexist with minimal pain. Time permitting, >> I'll put together some suggested text for your document that talks >> (in general terms) about how these mechanisms can interact with each >> other in a sane fashion. >> >> ----- >> >> I *do* have some of the same reservations as Paul does about >> nicknames. >> >> As has been brought up repeatedly: nicknames are most emphatically >> not an IM-only issue. The representation of conference participants >> is an extremely generalizable problem, and I can't as easily see how >> to harmonize two different mechanisms. >> >> In other words, the nickname reservation protocol that you're >> defining with the NICKNAME mechanism in MSRP shouldn't be limited to >> MSRP. My suggestion, for what it's worth, is that you (1) split the >> nickname reservation mechanism out into a separate draft, and (2) use >> either SIP or the XCON Conference Control Protocol instead of MSRP. >> >> ----- >> >> As a minor additional issue: one of the fundamental precepts of the >> conferencing framework (even pre-XCON) was that non-conference-aware >> participants should be able to participate in conferences, albeit >> with less control of the conference itself. To that end, it would >> probably be beneficial to indicate how participants who don't have >> CPIM clients will work. >> >> I think there are sensible ways of addressing this (e.g. if such a >> user sends a message, then the MSRP mixer adds a CPIM envelope that >> includes the user's identity, as learned during session >> establishment) -- they should probably be called out so that >> implementors of MSRP mixers will have some guidance around how they >> should behave.. >> >> /a >> >> _______________________________________________ >> 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 Sun Mar 19 17:51:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6kL-00088W-LJ; Sun, 19 Mar 2006 17:51:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6kJ-00087v-SU for simple@ietf.org; Sun, 19 Mar 2006 17:51:35 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL6kI-0006Gc-FL for simple@ietf.org; Sun, 19 Mar 2006 17:51:35 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JMoCk9029449; Mon, 20 Mar 2006 00:50:13 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 00:51:32 +0200 Received: from [10.241.58.189] ([10.241.58.189]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Mar 2006 00:51:32 +0200 Message-ID: <441DE072.4020907@nokia.com> Date: Mon, 20 Mar 2006 00:51:30 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Hisham Khartabil Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt References: <43F07211.9040107@nokia.com> <441CA79C.4000708@nostrum.com> <39aa024240605fefdbf798e662c5dd0b@telio.no> In-Reply-To: <39aa024240605fefdbf798e662c5dd0b@telio.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2006 22:51:32.0849 (UTC) FILETIME=[AB143E10:01C64BA7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Miguel Garcia , Adam Roach , "'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: , Errors-To: simple-bounces@ietf.org Hi Hisham, ext Hisham Khartabil wrote: > Speaking of nicknames. I don't understand why we need the MSRP extension > NICKNAME to reserve a nickname for a chatroom. One would think that the > nickname was reserved when the user joined the chatroom using the SIP > From header field. No, you would use the From header field to authenticate yourself when joining. So From is your "real" name. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Mar 19 17:56:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6pH-0003Cy-Lu; Sun, 19 Mar 2006 17:56:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6pF-0003By-Ny for simple@ietf.org; Sun, 19 Mar 2006 17:56:41 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL6pE-0006Sw-B4 for simple@ietf.org; Sun, 19 Mar 2006 17:56:41 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JMudrv018949; Mon, 20 Mar 2006 00:56:39 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 00:56:38 +0200 Received: from [10.241.58.189] ([10.241.58.189]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Mar 2006 00:56:38 +0200 Message-ID: <441DE1A4.1070906@nokia.com> Date: Mon, 20 Mar 2006 00:56:36 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Hisham Khartabil Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt References: <43F07211.9040107@nokia.com> <441CA79C.4000708@nostrum.com> <39aa024240605fefdbf798e662c5dd0b@telio.no> <5adc47eec39ea19ff23120ef0c1d67c9@telio.no> In-Reply-To: <5adc47eec39ea19ff23120ef0c1d67c9@telio.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2006 22:56:38.0781 (UTC) FILETIME=[616DC2D0:01C64BA8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Miguel Garcia , Adam Roach , "'simple@ietf.org' 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: , Errors-To: simple-bounces@ietf.org Hi Hisham, ext Hisham Khartabil wrote: > And one other thing about nicknames :) > > This might be a matter of taste. Would a URI parameter be more > appropriate. I.e. Instead of this > > sip:nordicguy%40room34@example.com > > you have this > > sip:room34@example.com;nickname="nordicguy" This is another option, yes. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Mar 19 17:58:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6qh-0004J7-Gb; Sun, 19 Mar 2006 17:58:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6qf-0004J2-SZ for simple@ietf.org; Sun, 19 Mar 2006 17:58:09 -0500 Received: from [207.14.217.166] (helo=server) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL6qf-0006WC-Ff for simple@ietf.org; Sun, 19 Mar 2006 17:58:09 -0500 Received: from [204.96.114.213] ([204.96.114.213]) by server (8.12.8/8.12.8) with SMTP id k2JLV82x031888; Sun, 19 Mar 2006 16:31:09 -0500 In-Reply-To: <441DE072.4020907@nokia.com> References: <43F07211.9040107@nokia.com> <441CA79C.4000708@nostrum.com> <39aa024240605fefdbf798e662c5dd0b@telio.no> <441DE072.4020907@nokia.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2dccf37ddb982a02579df05041a09f9f@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt Date: Sun, 19 Mar 2006 23:58:39 +0100 To: Aki Niemi X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Miguel Garcia , Adam Roach , "'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: , Errors-To: simple-bounces@ietf.org So let me understand. You join the chat room, then as a second step reserve your nickname? I don't think this is what we want. How about a Preferred-Identity header field or an a=nickname SDP attribute that carries the nickname URI. Or even in the request-URI. I think the nickname should be set up while "joining" and not after you join that chatroom. Hisham On Mar 19, 2006, at 11:51 PM, Aki Niemi wrote: > Hi Hisham, > > ext Hisham Khartabil wrote: >> Speaking of nicknames. I don't understand why we need the MSRP >> extension >> NICKNAME to reserve a nickname for a chatroom. One would think that >> the >> nickname was reserved when the user joined the chatroom using the SIP >> From header field. > > No, you would use the From header field to authenticate yourself when > joining. So From is your "real" name. > > Cheers, > Aki > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Mar 19 18:04:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6wb-0008LW-J1; Sun, 19 Mar 2006 18:04:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6wa-0008LR-3v for simple@ietf.org; Sun, 19 Mar 2006 18:04:16 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL6wY-0006hQ-MQ for simple@ietf.org; Sun, 19 Mar 2006 18:04:16 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JN4D2u024009; Mon, 20 Mar 2006 01:04:13 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 01:04:13 +0200 Received: from [10.241.58.189] ([10.241.58.189]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Mar 2006 01:04:13 +0200 Message-ID: <441DE36A.8040706@nokia.com> Date: Mon, 20 Mar 2006 01:04:10 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Hisham Khartabil Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt References: <43F07211.9040107@nokia.com> <441CA79C.4000708@nostrum.com> <39aa024240605fefdbf798e662c5dd0b@telio.no> <441DE072.4020907@nokia.com> <2dccf37ddb982a02579df05041a09f9f@telio.no> In-Reply-To: <2dccf37ddb982a02579df05041a09f9f@telio.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2006 23:04:13.0647 (UTC) FILETIME=[708CCDF0:01C64BA9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Miguel Garcia , Adam Roach , "'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: , Errors-To: simple-bounces@ietf.org ext Hisham Khartabil wrote: > So let me understand. You join the chat room, then as a second step > reserve your nickname? I don't think this is what we want. That's what all other chats do currently. > How about a Preferred-Identity header field or an a=nickname SDP > attribute that carries the nickname URI. Or even in the request-URI. Yeah, we thought about doing somthing like this in O/A, but the difficulty is in that the server needs to reject if there's a conflict, and perhaps suggest an alternate nickname. Then we thought about some session precondition for nicknames, but that made our heads explode Dean-style. The next day we defined the NICKNAME method. > I think the nickname should be set up while "joining" and not after you > join that chatroom. In practice, this is done while joining. But you also need to be able to change your nickname while in the chat already. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Mar 19 18:36:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL7S4-0004Ic-W6; Sun, 19 Mar 2006 18:36:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL7S4-0004IX-2w for simple@ietf.org; Sun, 19 Mar 2006 18:36:48 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL7S2-0007xo-MA for simple@ietf.org; Sun, 19 Mar 2006 18:36:48 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JNYbfA025414; Mon, 20 Mar 2006 01:34:37 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 01:36:45 +0200 Received: from [10.241.58.189] ([10.241.58.189]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Mar 2006 01:36:44 +0200 Message-ID: <441DEB05.80908@nokia.com> Date: Mon, 20 Mar 2006 01:36:37 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Hisham Khartabil Subject: Re: [Simple] 'chatroom' SDP Attribute in simple-chat References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2006 23:36:45.0016 (UTC) FILETIME=[FBA81580:01C64BAD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: "'simple@ietf.org' 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: , Errors-To: simple-bounces@ietf.org ext Hisham Khartabil wrote: > I'm not convinced that this is the correct way to learn about the > chatroom/conference capabilities. I would think this is out of scope of > this draft. Learning conference room capabilities is definitely not in > scope here. How would you suggest these chat room capabilities (namely, support for nicknames and private-messages) are communicated? And why is it not in scope of this draft when this draft after all defines those features? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Mar 19 18:56:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL7ks-0008FQ-Ma; Sun, 19 Mar 2006 18:56:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL7kr-0008FE-93 for simple@ietf.org; Sun, 19 Mar 2006 18:56:13 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL7kq-0000Vi-Pe for simple@ietf.org; Sun, 19 Mar 2006 18:56:13 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2JNu7bu020553; Mon, 20 Mar 2006 01:56:12 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 01:56:10 +0200 Received: from [10.241.58.189] ([10.241.58.189]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Mar 2006 01:56:09 +0200 Message-ID: <441DEF97.2050108@nokia.com> Date: Mon, 20 Mar 2006 01:56:07 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Adam Roach Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt References: <43F07211.9040107@nokia.com> <441CA79C.4000708@nostrum.com> In-Reply-To: <441CA79C.4000708@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2006 23:56:10.0447 (UTC) FILETIME=[B24EBDF0:01C64BB0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Miguel Garcia , "'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: , Errors-To: simple-bounces@ietf.org Inline. ext Adam Roach wrote: > By and large, this is far more palatable than previous versions. I'm > still a little apprehensive about the fact that we will ultimately end > up with more than one way to send messages to a subset of participants > (either using the "To" CPIM field *or* using the conference control > protocol), but I have convinced myself that these mechanisms can > probably coexist with minimal pain. Time permitting, I'll put together > some suggested text for your document that talks (in general terms) > about how these mechanisms can interact with each other in a sane fashion. That text will be much appreciated. > I *do* have some of the same reservations as Paul does about nicknames. > > As has been brought up repeatedly: nicknames are most emphatically not > an IM-only issue. The representation of conference participants is an > extremely generalizable problem, and I can't as easily see how to > harmonize two different mechanisms. What we are essentially doing is creating a new namespace as strictly a sub-namespace under the conference or chat room name. I think this is the only reasonable way forward, because nicknames in any other, global namespace really is a big problem, since that is really more a general use anonymizing service we end up defining. > In other words, the nickname reservation protocol that you're defining > with the NICKNAME mechanism in MSRP shouldn't be limited to MSRP. My > suggestion, for what it's worth, is that you (1) split the nickname > reservation mechanism out into a separate draft, and (2) use either SIP > or the XCON Conference Control Protocol instead of MSRP. I think these two are actually reasonable suggestions, as long as the same disclaimer we have in the draft still holds (namely, scope it for a particular room only, first-come-first-served policy, defining "sticky" nicknames out-of-scope, etc.). As a forward-warning, the current draft talks about sidebars as being one of the core features of chat rooms of today, but it doesn't define a mechanism for reserving such sidebars within a chat room. This is planned for the next version. ;) Essentially, sidebars within a chat room are similar to nicknames in that it's simply another sub-namespace to the chat room name. To reserve a sidebar, we could define a similar mechanism to what's already defined for nicknames. The only difference (in addition to method name :) would be that sidebars would presumably need to be both opened and closed. This proposal didn't make it to the draft, and I was supposed to send text to the list for a proposal, but haven't until now. Of course, I was thinking of a pair of OPEN-SIDEBAR, CLOSE-SIDEBAR methods in MSRP, but surely this could be done with SIP and/or XCON as well. Joining, asking others to join and leaving sidebars would use SIP INVITE, REFER, and BYE. > As a minor additional issue: one of the fundamental precepts of the > conferencing framework (even pre-XCON) was that non-conference-aware > participants should be able to participate in conferences, albeit with > less control of the conference itself. To that end, it would probably be > beneficial to indicate how participants who don't have CPIM clients will > work. Good point. > I think there are sensible ways of addressing this (e.g. if such a user > sends a message, then the MSRP mixer adds a CPIM envelope that includes > the user's identity, as learned during session establishment) -- they > should probably be called out so that implementors of MSRP mixers will > have some guidance around how they should behave.. Yes, and presumably, the chat server would need to decapsulate the messages from CPIM and send it in plain text, *possibly* copying the meta-data from the CPIM header into this plain text message as well. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Mar 19 22:31:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLB6b-0002VE-F3; Sun, 19 Mar 2006 22:30:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLB6a-0002SS-2D for simple@ietf.org; Sun, 19 Mar 2006 22:30:52 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLB6Y-0006rq-P7 for simple@ietf.org; Sun, 19 Mar 2006 22:30:52 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWE00KPPPM0R5@usaga01-in.huawei.com> for simple@ietf.org; Sun, 19 Mar 2006 19:27:37 -0800 (PST) Received: from huawei.com ([172.17.1.101]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWE00J6DPLZG8@usaga01-in.huawei.com> for simple@ietf.org; Sun, 19 Mar 2006 19:27:36 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [130.129.65.236]) by szxmc01-in.huawei.com (mshttpd); Mon, 20 Mar 2006 11:30:52 +0800 Date: Mon, 20 Mar 2006 11:30:52 +0800 From: wangxiao 39649 Subject: =?gb2312?B?u9i4tA==?=:Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt To: Aki Niemi Message-id: <1356e84135af51.135af511356e84@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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: , Errors-To: simple-bounces@ietf.org inline ----- =D4=AD=D3=CA=BC=FE ----- =B4=D3=3A Aki Niemi =3Caki=2Eniemi=40nokia=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=D2=BB=2C =C8=FD=D4=C2 20=C8=D5=2C 2006 =C9=CF= =CE=E77=3A04 =D6=F7=CC=E2=3A Re=3A =5BSimple=5D MSRP chat=3A draft-niemi-simple-chat-0= 4=2Etxt =3E = =3E = =3E ext Hisham Khartabil wrote=3A =3E =3E So let me understand=2E You join the chat room=2C then as a secon= d step =3E =3E reserve your nickname=3F I don=27t think this is what we want=2E =3E = =3E That=27s what all other chats do currently=2E =3E = =3E =3E How about a Preferred-Identity header field or an a=3Dnickname SD= P =3E =3E attribute that carries the nickname URI=2E Or even in the request= -URI=2E =3E = =3E Yeah=2C we thought about doing somthing like this in O/A=2C but the =3E difficulty is in that the server needs to reject if there=27s a = =3E conflict=2Cand perhaps suggest an alternate nickname=2E =3E = I think it is a bad experience to user if server reject user to join chat= room with nickname conflicting=2E When a chat room has many participants=2C nickname conflicting will be ap= peared frequently=2C and a participant will try to join chat room for several times with this reason=2E = =3E Then we thought about some session precondition for nicknames=2C but = =3E thatmade our heads explode Dean-style=2E The next day we defined the = =3E NICKNAMEmethod=2E =3E = =3E =3E I think the nickname should be set up while =22joining=22 and not= = =3E after you =3E =3E join that chatroom=2E =3E = =3E In practice=2C this is done while joining=2E But you also need to be = =3E able to =3E change your nickname while in the chat already=2E =3E = =3E Cheers=2C =3E Aki =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E Simple mailing list =3E Simple=40ietf=2Eorg =3E https=3A//www1=2Eietf=2Eorg/mailman/listinfo/simple =3E _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 02:48:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLF7b-0003Kc-KO; Mon, 20 Mar 2006 02:48:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLF7Z-0003KX-WF for simple@ietf.org; Mon, 20 Mar 2006 02:48:10 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLF7Y-00071l-Hy for simple@ietf.org; Mon, 20 Mar 2006 02:48:09 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2K7kehZ004653; Mon, 20 Mar 2006 09:46:46 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 09:48:05 +0200 Received: from [127.0.0.1] ([172.21.34.185]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Mar 2006 09:48:05 +0200 Message-ID: <441E5E34.7000805@nokia.com> Date: Mon, 20 Mar 2006 09:48:04 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt References: <43F07211.9040107@nokia.com> <441CA79C.4000708@nostrum.com> <39aa024240605fefdbf798e662c5dd0b@telio.no> In-Reply-To: <39aa024240605fefdbf798e662c5dd0b@telio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2006 07:48:05.0286 (UTC) FILETIME=[9F444C60:01C64BF2] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Adam Roach , "'simple@ietf.org'" , Niemi Aki 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: , Errors-To: simple-bounces@ietf.org Hisham Khartabil wrote: > Speaking of nicknames. I don't understand why we need the MSRP extension > NICKNAME to reserve a nickname for a chatroom. One would think that the > nickname was reserved when the user joined the chatroom using the SIP > From header field. > The SIP From header is not suitable, because it does not guarantee that the nickname is not already in use by someone else. Additionally, I think we should keep using the From header in SIP as we are currently doing, which in most cases (with the exception of anonymous URIs), it indicates the routable SIP URI of the sender. A nickname shouldn't be routable, so in my opinion it does not fit there. > Thanks, > Hisham > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 02:48:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLF8D-0004Nj-FR; Mon, 20 Mar 2006 02:48:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLF8B-0004Jh-VK for simple@ietf.org; Mon, 20 Mar 2006 02:48:47 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLF8A-000729-IF for simple@ietf.org; Mon, 20 Mar 2006 02:48:47 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2K7mhWq017149; Mon, 20 Mar 2006 09:48:45 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 09:48:43 +0200 Received: from [127.0.0.1] ([172.21.34.185]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Mar 2006 09:48:43 +0200 Message-ID: <441E5E5A.9000605@nokia.com> Date: Mon, 20 Mar 2006 09:48:42 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ext Hisham Khartabil Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt References: <43F07211.9040107@nokia.com> <441CA79C.4000708@nostrum.com> <39aa024240605fefdbf798e662c5dd0b@telio.no> <5adc47eec39ea19ff23120ef0c1d67c9@telio.no> In-Reply-To: <5adc47eec39ea19ff23120ef0c1d67c9@telio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2006 07:48:43.0113 (UTC) FILETIME=[B5D03D90:01C64BF2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Adam Roach , "'simple@ietf.org' WG" , Niemi Aki 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: , Errors-To: simple-bounces@ietf.org Hisham Khartabil wrote: > And one other thing about nicknames :) > > This might be a matter of taste. Would a URI parameter be more > appropriate. I.e. Instead of this > > sip:nordicguy%40room34@example.com > > you have this > > sip:room34@example.com;nickname="nordicguy" > > Thanks, > Hisham > I have no problem with this approach. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 02:53:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLFD4-0007HH-Er; Mon, 20 Mar 2006 02:53:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLFD3-0007F2-5r for simple@ietf.org; Mon, 20 Mar 2006 02:53:49 -0500 Received: from wproxy.gmail.com ([64.233.184.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLFD0-0007Bq-Tm for simple@ietf.org; Mon, 20 Mar 2006 02:53:49 -0500 Received: by wproxy.gmail.com with SMTP id i31so1107755wra for ; Sun, 19 Mar 2006 23:53:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=tCogr0O/+e2FHaR64n2+Eq/WF2M9OORgSOA2di+jc9k/xzWoOPPbDtbxcxepaLR22HuvcLiXP5iDb39FxOgVEcq22ylfL/U9Wnrw7tcvYm1pmW166o4XxRhoayB7kusQofvnxG+4FP1sk0Xh5hFzGXWfVRj8c9l5uhxR2vHM/xg= Received: by 10.54.67.14 with SMTP id p14mr1534326wra; Sun, 19 Mar 2006 23:53:45 -0800 (PST) Received: by 10.54.93.10 with HTTP; Sun, 19 Mar 2006 23:53:45 -0800 (PST) Message-ID: <95d59cef0603192353u546b7e88y15be8a50dded2233@mail.gmail.com> Date: Mon, 20 Mar 2006 09:53:45 +0200 From: "Jussi K. Virtanen" To: "Miguel A. Garcia-Martin" , "Aki Niemi" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF SIMPLE Subject: [Simple] MSRP chat and IMDN 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: , Errors-To: simple-bounces@ietf.org Hi, In draft-niemi-simple-chat-04, a new status code, 427, is specified for use in a situation in which the MSRP switch is unable to forward a message to some of the intended participants. I think it would be more appropriate to use, for example, IMDN (draft-burger-simple-imdn-03) for this purpose because the forwarding mechanism in the MSRP switch is based on CPIM instead of MSRP. IMDN is anyway needed if a participant wishes to request delivery notification. Delivery status in MSRP cannot be used because each participant has its own MSRP session with the MSRP switch. Best Regards, -- Jussi K. Virtanen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 03:03:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLFLy-00047K-Sx; Mon, 20 Mar 2006 03:03:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLFLx-00047F-Hi for simple@ietf.org; Mon, 20 Mar 2006 03:03:01 -0500 Received: from wproxy.gmail.com ([64.233.184.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLFLw-0007YC-Ae for simple@ietf.org; Mon, 20 Mar 2006 03:03:01 -0500 Received: by wproxy.gmail.com with SMTP id 69so914639wra for ; Mon, 20 Mar 2006 00:02:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=q/WG3rB+haMSJYYpy/qAgrGn/O6uDxwi2Xo9ym6es7DUXTVkiCuqP/oMTr8H5+K1mnumm5xxN5Wa6v72QnC6bve7hn6O7c6+9KcK2Cy/l+hIdMPqpfAdxIVzQQSwBOnB/1rLSUMQCaNZXzNg/wFBpf6Aik9sqhnC/ha/OgypWB4= Received: by 10.54.70.12 with SMTP id s12mr3506198wra; Mon, 20 Mar 2006 00:02:59 -0800 (PST) Received: by 10.54.93.10 with HTTP; Mon, 20 Mar 2006 00:02:59 -0800 (PST) Message-ID: <95d59cef0603200002l294c5432x77a42fd87dcd51a2@mail.gmail.com> Date: Mon, 20 Mar 2006 10:02:59 +0200 From: "Jussi K. Virtanen" To: "Adam Roach" Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt In-Reply-To: <441CA79C.4000708@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43F07211.9040107@nokia.com> <441CA79C.4000708@nostrum.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IETF SIMPLE 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: , Errors-To: simple-bounces@ietf.org Hi, On 2006-03-19, Adam Roach wrote: > As a minor additional issue: one of the fundamental > precepts of the conferencing framework (even pre-XCON) was > that non-conference-aware participants should be able to > participate in conferences, albeit with less control of > the conference itself. To that end, it would probably be > beneficial to indicate how participants who don't have > CPIM clients will work. Shouldn't an MSRP endpoint implement CPIM always? The draft draft-ietf-simple-message-sessions-14 says as follows: All MSRP endpoints MUST support the message/cpim type, and SHOULD support the S/MIME[7] features of that format. Thus, even a conference-unaware participant should be able to comply with a request to use "message/cpim" as a wrapper. Best Regards, -- Jussi K. Virtanen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 03:34:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLFqD-0005ik-31; Mon, 20 Mar 2006 03:34:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLFqB-0005hl-7V for simple@ietf.org; Mon, 20 Mar 2006 03:34:15 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLFq8-0008Vt-Nx for simple@ietf.org; Mon, 20 Mar 2006 03:34:15 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2K8Wn55017566; Mon, 20 Mar 2006 10:32:49 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 10:34:09 +0200 Received: from [127.0.0.1] ([172.21.34.185]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Mar 2006 10:34:09 +0200 Message-ID: <441E6901.2080902@nokia.com> Date: Mon, 20 Mar 2006 10:34:09 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Jussi K. Virtanen" References: <95d59cef0603192353u546b7e88y15be8a50dded2233@mail.gmail.com> In-Reply-To: <95d59cef0603192353u546b7e88y15be8a50dded2233@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2006 08:34:09.0432 (UTC) FILETIME=[0ED38180:01C64BF9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Aki Niemi , IETF SIMPLE Subject: [Simple] Re: MSRP chat and IMDN 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: , Errors-To: simple-bounces@ietf.org Hi Jussi: I agree that at some point in time we need to synchronize MSRP chat with IMDN, and it is not our intention to specify a mechanism if we can reuse IMDN. BUT: draft-burger-simple-imdn-03 does not provide a mechanism to inform whether a message has been delivered or not, instead, the draft relies on the protocol (MSRP). Instead, draft-khartabil-simple-im-receipts-00 provides a mechanism for delivery receipt. So, depending on what the final IMDN mechanism is able to provide, we will need or not to extend MSRP. BR, Miguel Jussi K. Virtanen wrote: > Hi, > > In draft-niemi-simple-chat-04, a new status code, 427, is > specified for use in a situation in which the MSRP switch > is unable to forward a message to some of the intended > participants. > > I think it would be more appropriate to use, for example, > IMDN (draft-burger-simple-imdn-03) for this purpose because > the forwarding mechanism in the MSRP switch is based on CPIM > instead of MSRP. > > IMDN is anyway needed if a participant wishes to request > delivery notification. Delivery status in MSRP cannot be > used because each participant has its own MSRP session with > the MSRP switch. > > > Best Regards, > > -- > Jussi K. Virtanen -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 04:50:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLH1Y-0000Yb-Nr; Mon, 20 Mar 2006 04:50:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLH1W-0000RL-PD for simple@ietf.org; Mon, 20 Mar 2006 04:50:02 -0500 Received: from wproxy.gmail.com ([64.233.184.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLH1V-00031M-Hx for simple@ietf.org; Mon, 20 Mar 2006 04:50:02 -0500 Received: by wproxy.gmail.com with SMTP id 50so954489wri for ; Mon, 20 Mar 2006 01:50:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z10X12Abd8JqOCu+dXEW6wTGwwiLUAJZZebPq/4hUwUNPm1jkKEDSROhiq2ROUbSHbu8GxmP1NjHYE5aUI5U0PmAgVO+f7oCSnuhxxk5Ibk33rFwz8YRQau4TzeyW2aO/k0L+qr1zYssmVbeijsL+3uTi/mqj+HS5LiQY1XBf9s= Received: by 10.54.70.12 with SMTP id s12mr3548647wra; Mon, 20 Mar 2006 01:50:00 -0800 (PST) Received: by 10.54.93.10 with HTTP; Mon, 20 Mar 2006 01:50:00 -0800 (PST) Message-ID: <95d59cef0603200150j732f0c9dh34c83a1cee4c151@mail.gmail.com> Date: Mon, 20 Mar 2006 11:50:00 +0200 From: "Jussi K. Virtanen" To: "Miguel Garcia" In-Reply-To: <441E6901.2080902@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <95d59cef0603192353u546b7e88y15be8a50dded2233@mail.gmail.com> <441E6901.2080902@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Eric Burger , IETF SIMPLE Subject: [Simple] Re: MSRP chat and IMDN 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: , Errors-To: simple-bounces@ietf.org Hi Miguel, On 2006-03-20, Miguel Garcia wrote: > I agree that at some point in time we need to synchronize > MSRP chat with IMDN, and it is not our intention to specify > a mechanism if we can reuse IMDN. > BUT: draft-burger-simple-imdn-03 does not provide a mechanism > to inform whether a message has been delivered or not, instead, > the draft relies on the protocol (MSRP). Instead, > draft-khartabil-simple-im-receipts-00 provides a mechanism for > delivery receipt. So, depending on what the final IMDN mechanism > is able to provide, we will need or not to extend MSRP. Couldn't the "first-recipient" mechanism of IMDN, described in Section 9.3.1 of draft-burger-simple-imdn-03, be extended from B2BUAs to MSRP switches as well? An excerpt from the section: o If the B2BUA forwards the message, it SHOULD return an "processed" IMDN, mindful of the privacy considerations enumerated in Section 4. o If there was an error processing the message, the B2BUA SHOULD return an "error" IMDN, mindful of the privacy considerations enumerated in Section 4. I believe an "error" IMDN could be a substitute for a 427 response. draft-khartabil-simple-im-receipts-00 explicitly prohibits requests of delivery receipts for messages that are transferred on top of MSRP (Section 7.1.1.). I see that as a problem because the delivery status in MSRP is bound to an MSRP session but one CPIM message can traverse on its way over multiple MSRP sessions, as it does in MSRP chat (draft-niemi-simple-chat-04). BR, -- Jussi K. Virtanen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 05:51:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLHzR-0003YL-EM; Mon, 20 Mar 2006 05:51:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLHzP-0003YG-Nz for simple@ietf.org; Mon, 20 Mar 2006 05:51:55 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLHzO-0005AN-9f for simple@ietf.org; Mon, 20 Mar 2006 05:51:55 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2KAncWo012673; Mon, 20 Mar 2006 12:49:40 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 12:50:52 +0200 Received: from [127.0.0.1] ([172.21.34.185]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Mar 2006 12:50:53 +0200 Message-ID: <441E890C.6010207@nokia.com> Date: Mon, 20 Mar 2006 12:50:52 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Jussi K. Virtanen" References: <95d59cef0603192353u546b7e88y15be8a50dded2233@mail.gmail.com> <441E6901.2080902@nokia.com> <95d59cef0603200150j732f0c9dh34c83a1cee4c151@mail.gmail.com> In-Reply-To: <95d59cef0603200150j732f0c9dh34c83a1cee4c151@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2006 10:50:53.0018 (UTC) FILETIME=[288B63A0:01C64C0C] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Eric Burger , IETF SIMPLE Subject: [Simple] Re: MSRP chat and IMDN 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: , Errors-To: simple-bounces@ietf.org Hi Jussi: Well, the case we are considering is not a full error, because some of the URIs are reachable, others aren't. I guess the mechanism could be extended to indicate "partial delivery", and include a list of URIs for which delivery failed. Certainly, we need a bit more of discussion on this, but first we (SIMPLE) need to take a determination of which path to follow (Eric's or Hisham's draft). BR, Miguel Jussi K. Virtanen wrote: > Hi Miguel, > > On 2006-03-20, Miguel Garcia wrote: >> I agree that at some point in time we need to synchronize >> MSRP chat with IMDN, and it is not our intention to specify >> a mechanism if we can reuse IMDN. > >> BUT: draft-burger-simple-imdn-03 does not provide a mechanism >> to inform whether a message has been delivered or not, instead, >> the draft relies on the protocol (MSRP). Instead, >> draft-khartabil-simple-im-receipts-00 provides a mechanism for >> delivery receipt. So, depending on what the final IMDN mechanism >> is able to provide, we will need or not to extend MSRP. > > Couldn't the "first-recipient" mechanism of IMDN, described in > Section 9.3.1 of draft-burger-simple-imdn-03, be extended from > B2BUAs to MSRP switches as well? An excerpt from the section: > > o If the B2BUA forwards the message, it SHOULD return an > "processed" IMDN, mindful of the privacy considerations > enumerated in Section 4. > o If there was an error processing the message, the B2BUA > SHOULD return an "error" IMDN, mindful of the privacy > considerations enumerated in Section 4. > > I believe an "error" IMDN could be a substitute for a 427 > response. > > draft-khartabil-simple-im-receipts-00 explicitly prohibits > requests of delivery receipts for messages that are transferred > on top of MSRP (Section 7.1.1.). I see that as a problem because > the delivery status in MSRP is bound to an MSRP session but > one CPIM message can traverse on its way over multiple MSRP > sessions, as it does in MSRP chat (draft-niemi-simple-chat-04). > > > BR, > > -- > Jussi K. Virtanen -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 06:11:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLIIR-00006J-Ss; Mon, 20 Mar 2006 06:11:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLIIQ-0008W2-E4 for simple@ietf.org; Mon, 20 Mar 2006 06:11:34 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLIIO-000684-Uj for simple@ietf.org; Mon, 20 Mar 2006 06:11:34 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2KBBRGg027814; Mon, 20 Mar 2006 13:11:32 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 13:11:07 +0200 Received: from [127.0.0.1] ([172.21.34.185]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Mar 2006 13:11:07 +0200 Message-ID: <441E8DCA.4070009@nokia.com> Date: Mon, 20 Mar 2006 13:11:06 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] 'chatroom' SDP Attribute in simple-chat References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2006 11:11:07.0822 (UTC) FILETIME=[FC9FC4E0:01C64C0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "'simple@ietf.org' 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: , Errors-To: simple-bounces@ietf.org The reason for learning this capabilities in SDP is purely pragmatical. You wouldn't like to send private messages through the chat server, thinking that the chat server implements that draft, and then find out that your messages have been distributed to the whole roaster because the chat server didn't implement the draft. In earlier versions of this draft we implemented a DISTSEND method, so that if the chat server does not implement the draft, it will reply back with a 4xx response, but the whole point is that the private message wouldn't be distributed. We got quite many comments in the mailing list that private messages shouldn't require the implementation of a new method, so we came with the conclusion that, due to the MSRP design, where capabilities are negotiated in SDP, the only alternative was to design capabilities and negotiated in SDP (which is exactly what SDP is suppose to do). So, if you find a reasonable alternative solution, I am happy to consider it, but the requirement is obvious, so we need to design a solution for it. /Miguel Hisham Khartabil wrote: > I'm not convinced that this is the correct way to learn about the > chatroom/conference capabilities. I would think this is out of scope of > this draft. Learning conference room capabilities is definitely not in > scope here. > > Hisham > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 06:25:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLIVn-00084Q-Hc; Mon, 20 Mar 2006 06:25:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLIVm-00084L-IT for simple@ietf.org; Mon, 20 Mar 2006 06:25:22 -0500 Received: from relay01s.clb.oleane.net ([213.56.31.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLIVl-0006Vk-43 for simple@ietf.org; Mon, 20 Mar 2006 06:25:22 -0500 Received: from smtp11.clb.oleane.net (smtp11.clb.oleane.net [213.56.31.48]) by relay01s.clb.oleane.net with ESMTP id k2KBPCHN020692 for ; Mon, 20 Mar 2006 12:25:19 +0100 Received: from Pavillonquatre ([194.3.133.88]) by smtp11.clb.oleane.net with ESMTP id k2KAngpE019799 for ; Mon, 20 Mar 2006 11:50:37 +0100 Message-Id: <200603201050.k2KAngpE019799@smtp11.clb.oleane.net> From: "Chantal Ladouce" To: Date: Mon, 20 Mar 2006 11:49:52 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZMDASOr8BvigHIQGeuA67npbAJtg== X-Spam-Score: 0.3 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Subject: [Simple] Wireless WiFi Convergence 2006 Conference & Exhibition - Paris - France 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="===============0186034737==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0186034737== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C64C14.66A64F30" This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C64C14.66A64F30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 1st Edition of the Wireless WiFi Convergence 2006 Conference & Exhibition will stand in Paris next May 16 - 19, 2006 Only 2 weeks left to take advantage of our Early Bird Offer! Register before the 31st of March 2006 and benefit from a 10% discount on the registration fees. To register, please go to: http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006registratio n.htm ------=_NextPart_000_0031_01C64C14.66A64F30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 1st = Edition of the Wireless WiFi Convergence 2006 Conference & = Exhibition

=

will stand in Paris next May 16 - 19, 2006

=

 

=

Only 2 weeks left to take advantage of our = Early Bird Offer! =

Register before the 31st of March = 2006 and benefit from a 10% discount on the registration fees. 

 

To register, please go = to:

http://www.upperside.fr/wirelessconvergence2006/wwconv= ergence2006registration.htm

 

------=_NextPart_000_0031_01C64C14.66A64F30-- --===============0186034737== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0186034737==-- From simple-bounces@ietf.org Mon Mar 20 09:41:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLZT-0007OI-59; Mon, 20 Mar 2006 09:41:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLZR-0007LT-OB for simple@ietf.org; Mon, 20 Mar 2006 09:41:21 -0500 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLZQ-0004Ne-Bg for simple@ietf.org; Mon, 20 Mar 2006 09:41:21 -0500 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 Date: Mon, 20 Mar 2006 15:41:13 +0100 Message-ID: <31721CD4D0090B4BA32CBA5E2C40AE9001F46A28@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Filtering: one issue still open Thread-Index: AcZMLFYNrmYlOOWJQ7S4H//FQDZg+A== From: To: X-OriginalArrivalTime: 20 Mar 2006 14:41:19.0315 (UTC) FILETIME=[59A8E230:01C64C2C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Simple] Filtering: one issue still 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: , Errors-To: simple-bounces@ietf.org Hi, draft-ietf-simple-filter-format-05 says: "The (filter's) element is used to identify the XML element or attribute, from the package specific XML document, whose value MUST change, compared to the "previous XML document", in order to activate the trigger and cause the content to be delivered. Previous XML document in this context refers to the last XML document that was selected for delivery to that specific subscription before any filter was applied to it." I understand that the "previous XML document" is the last notification that is sent to the subscriber, but without any 'what' filter applied on it. Simply said, the "previous XML document" is the whole presentity's presence document whose filtered piece was selected for delivery to the subscriber. Right? Now, I don't completely understand, what is "selected for delivery". Is it the information that passed the triggering only, or is it the information that was *really* sent to the subscriber? It is not the same, since after filtering, there is also the throttling component in the presence server that may cause the notification to be not sent, in fact. Please note, this is also connected to the filtering & throttling paradox I've posted here a few days ago. What is your opinion Hisham? (Other people are welcome to post suggestions too, of course :) Thank you very much. Best regards, Michal Burda _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 11:04:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMrc-0006ba-9v; Mon, 20 Mar 2006 11:04:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMrb-0006bS-Oq for simple@ietf.org; Mon, 20 Mar 2006 11:04:11 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLMra-0007jo-FB for simple@ietf.org; Mon, 20 Mar 2006 11:04:11 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by test-iport-1.cisco.com with ESMTP; 20 Mar 2006 08:04:10 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2KG49Yg019624; Mon, 20 Mar 2006 08:04:09 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 08:04:09 -0800 Received: from [10.21.97.35] ([10.21.97.35]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 08:04:07 -0800 Message-ID: <441ED265.1040307@cisco.com> Date: Mon, 20 Mar 2006 11:03:49 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt References: <43F07211.9040107@nokia.com> <441CA79C.4000708@nostrum.com> <39aa024240605fefdbf798e662c5dd0b@telio.no> <441DE072.4020907@nokia.com> <2dccf37ddb982a02579df05041a09f9f@telio.no> <441DE36A.8040706@nokia.com> In-Reply-To: <441DE36A.8040706@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2006 16:04:08.0890 (UTC) FILETIME=[EBC1D9A0:01C64C37] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Miguel Garcia , Adam Roach , "'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: , Errors-To: simple-bounces@ietf.org I want to know how nicknames relate to the roster of the conference. When joining the conference it will be common that the new participant may be willing to have the nickname disclosed in the roster, but not the actual participant URI. This affects requirements for the nickname assignment mechanism. Paul Aki Niemi wrote: > > ext Hisham Khartabil wrote: > >>So let me understand. You join the chat room, then as a second step >>reserve your nickname? I don't think this is what we want. > > > That's what all other chats do currently. > > >>How about a Preferred-Identity header field or an a=nickname SDP >>attribute that carries the nickname URI. Or even in the request-URI. > > > Yeah, we thought about doing somthing like this in O/A, but the > difficulty is in that the server needs to reject if there's a conflict, > and perhaps suggest an alternate nickname. > > Then we thought about some session precondition for nicknames, but that > made our heads explode Dean-style. The next day we defined the NICKNAME > method. > > >>I think the nickname should be set up while "joining" and not after you >>join that chatroom. > > > In practice, this is done while joining. But you also need to be able to > change your nickname while in the chat already. > > Cheers, > Aki > > _______________________________________________ > 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 Mar 20 11:05:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMtH-0007QL-Tq; Mon, 20 Mar 2006 11:05:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMtG-0007QG-Ka for simple@ietf.org; Mon, 20 Mar 2006 11:05:54 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLMtF-0007ou-CL for simple@ietf.org; Mon, 20 Mar 2006 11:05:54 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2KG5pSg033528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Mar 2006 10:05:51 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <441ED2DF.9050406@nostrum.com> Date: Mon, 20 Mar 2006 10:05:51 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jussi K. Virtanen" Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt References: <43F07211.9040107@nokia.com> <441CA79C.4000708@nostrum.com> <95d59cef0603200002l294c5432x77a42fd87dcd51a2@mail.gmail.com> In-Reply-To: <95d59cef0603200002l294c5432x77a42fd87dcd51a2@mail.gmail.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.130.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Adam Roach , IETF SIMPLE 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: , Errors-To: simple-bounces@ietf.org Jussi K. Virtanen wrote: >Hi, > >On 2006-03-19, Adam Roach wrote: > > >>As a minor additional issue: one of the fundamental >>precepts of the conferencing framework (even pre-XCON) was >>that non-conference-aware participants should be able to >>participate in conferences, albeit with less control of >>the conference itself. To that end, it would probably be >>beneficial to indicate how participants who don't have >>CPIM clients will work. >> >> > >Shouldn't an MSRP endpoint implement CPIM always? The draft >draft-ietf-simple-message-sessions-14 says as follows: > > All MSRP endpoints MUST support the message/cpim > type, and SHOULD support the S/MIME[7] features of > that format. > >Thus, even a conference-unaware participant should be able >to comply with a request to use "message/cpim" as a wrapper. > > > Good catch. Thanks for reminding me about this. Based on this, I think we need no additional text in the draft to address non-conference-aware clients. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 11:10:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMxj-0002Aq-Ti; Mon, 20 Mar 2006 11:10:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMxi-0002Ai-CX for simple@ietf.org; Mon, 20 Mar 2006 11:10:30 -0500 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.43) id 1FLMxh-00083R-3u for simple@ietf.org; Mon, 20 Mar 2006 11:10:30 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 20 Mar 2006 08:10:28 -0800 X-IronPort-AV: i="4.03,111,1141632000"; d="scan'208"; a="316259738:sNHT25417404" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2KGAS7T000291; Mon, 20 Mar 2006 08:10:28 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 08:10:28 -0800 Received: from [10.21.97.35] ([10.21.97.35]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 08:10:27 -0800 Message-ID: <441ED3F2.2030108@cisco.com> Date: Mon, 20 Mar 2006 11:10:26 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt References: <43F07211.9040107@nokia.com> <441CA79C.4000708@nostrum.com> <441DEF97.2050108@nokia.com> In-Reply-To: <441DEF97.2050108@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2006 16:10:28.0130 (UTC) FILETIME=[CDCD4820:01C64C38] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Miguel Garcia , ext Adam Roach , "'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: , Errors-To: simple-bounces@ietf.org Aki Niemi wrote: >>In other words, the nickname reservation protocol that you're defining >>with the NICKNAME mechanism in MSRP shouldn't be limited to MSRP. My >>suggestion, for what it's worth, is that you (1) split the nickname >>reservation mechanism out into a separate draft, and (2) use either SIP >>or the XCON Conference Control Protocol instead of MSRP. > > > I think these two are actually reasonable suggestions, as long as the > same disclaimer we have in the draft still holds (namely, scope it for a > particular room only, first-come-first-served policy, defining "sticky" > nicknames out-of-scope, etc.). I think it is ok if the mechanism doesn't require more than FCFS policy for assignment of names. But neither should it be restricted to such a policy. IMO sticky nicknames are quite important. It would be upsetting if each time I came to the simple chat room I had to wonder whether "fluffy" was still Cullen. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 11:52:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNci-0004Mh-Oe; Mon, 20 Mar 2006 11:52:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNch-0004Mc-Oo for simple@ietf.org; Mon, 20 Mar 2006 11:52:51 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLNcf-0001IC-2k for simple@ietf.org; Mon, 20 Mar 2006 11:52:51 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 2A363194490 for ; Mon, 20 Mar 2006 17:52:48 +0100 (CET) Received: from [130.129.134.123] ([130.129.134.123]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 17:51:00 +0100 In-Reply-To: <31721CD4D0090B4BA32CBA5E2C40AE9001F46A28@carrera.eu.tieto.com> References: <31721CD4D0090B4BA32CBA5E2C40AE9001F46A28@carrera.eu.tieto.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <23a39e44b716da69b9c9d23f1568942b@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Filtering: one issue still open Date: Mon, 20 Mar 2006 17:53:06 +0100 To: X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 20 Mar 2006 16:51:02.0280 (UTC) FILETIME=[78AB1880:01C64C3E] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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: , Errors-To: simple-bounces@ietf.org On Mar 20, 2006, at 3:41 PM, wrote: > Hi, > > draft-ietf-simple-filter-format-05 says: > > "The (filter's) element is used to identify the XML element > or > attribute, from the package specific XML document, whose value MUST > change, compared to the "previous XML document", in order to activate > the trigger and cause the content to be delivered. Previous XML > document in this context refers to the last XML document that was > selected for delivery to that specific subscription before any filter > was applied to it." > > I understand that the "previous XML document" is the last notification > that is sent to the subscriber, but without any 'what' filter applied > on > it. Simply said, the "previous XML document" is the whole presentity's > presence document whose filtered piece was selected for delivery to the > subscriber. Right? This is right. > > Now, I don't completely understand, what is "selected for delivery". Is > it the information that passed the triggering only, or is it the > information that was *really* sent to the subscriber? It is not the > same, since after filtering, there is also the throttling component in > the presence server that may cause the notification to be not sent, in > fact. I will reword this sentence in the Author's 48 hours since it is causing a lot of confusion. What you describe as the "previous XML document" is enough. Hisham > > Please note, this is also connected to the filtering & throttling > paradox I've posted here a few days ago. > > What is your opinion Hisham? (Other people are welcome to post > suggestions too, of course :) > > Thank you very much. > > > Best regards, > > > Michal Burda > > _______________________________________________ > 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 Mar 20 11:58:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNhf-0000yQ-L5; Mon, 20 Mar 2006 11:57:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNhe-0000yL-ET for simple@ietf.org; Mon, 20 Mar 2006 11:57:58 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLNhd-0001a0-MB for simple@ietf.org; Mon, 20 Mar 2006 11:57:58 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 7CB7219448D for ; Mon, 20 Mar 2006 17:57:56 +0100 (CET) Received: from [130.129.134.123] ([130.129.134.123]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 17:56:06 +0100 In-Reply-To: <441E8DCA.4070009@nokia.com> References: <441E8DCA.4070009@nokia.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <11eb7d5ef3618528871c3a8fa2438531@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] 'chatroom' SDP Attribute in simple-chat Date: Mon, 20 Mar 2006 17:58:16 +0100 To: Miguel Garcia X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 20 Mar 2006 16:56:06.0785 (UTC) FILETIME=[2E2ADF10:01C64C3F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "'simple@ietf.org' 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: , Errors-To: simple-bounces@ietf.org Capabilities of a conference server are not limited to private messages and chat specific features. There are other capabilities about other media that the user might be interested in learning about. Choosing to do this in SDP or not is not my concern right now. My concern is that any mechanism that we come up with for the user to learn the conference server capabilities needs to also take into consideration other media and not just IM. Hisham On Mar 20, 2006, at 12:11 PM, Miguel Garcia wrote: > The reason for learning this capabilities in SDP is purely > pragmatical. You wouldn't like to send private messages through the > chat server, thinking that the chat server implements that draft, and > then find out that your messages have been distributed to the whole > roaster because the chat server didn't implement the draft. > > In earlier versions of this draft we implemented a DISTSEND method, so > that if the chat server does not implement the draft, it will reply > back with a 4xx response, but the whole point is that the private > message wouldn't be distributed. > > We got quite many comments in the mailing list that private messages > shouldn't require the implementation of a new method, so we came with > the conclusion that, due to the MSRP design, where capabilities are > negotiated in SDP, the only alternative was to design capabilities and > negotiated in SDP (which is exactly what SDP is suppose to do). > > So, if you find a reasonable alternative solution, I am happy to > consider it, but the requirement is obvious, so we need to design a > solution for it. > > /Miguel > > Hisham Khartabil wrote: >> I'm not convinced that this is the correct way to learn about the >> chatroom/conference capabilities. I would think this is out of scope >> of this draft. Learning conference room capabilities is definitely >> not in scope here. >> Hisham >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 12:36:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLOIx-0002xB-Rj; Mon, 20 Mar 2006 12:36:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLOIw-0002w7-F7 for simple@ietf.org; Mon, 20 Mar 2006 12:36:30 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLOIu-0003Jw-Am for simple@ietf.org; Mon, 20 Mar 2006 12:36:30 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWF00HGPSRHXS@usaga01-in.huawei.com> for simple@ietf.org; Mon, 20 Mar 2006 09:33:17 -0800 (PST) Received: from jys3105061835 (DHCP-Wireless-131-204.ietf65.org [130.129.131.204]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IWF00FKXSREJJ@usaga01-in.huawei.com> for simple@ietf.org; Mon, 20 Mar 2006 09:33:16 -0800 (PST) Date: Mon, 20 Mar 2006 11:36:17 +0800 From: smile Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt To: Paul Kyzivat , Aki Niemi Message-id: <006001c64bcf$7316def0$cc838182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <43F07211.9040107@nokia.com> <441CA79C.4000708@nostrum.com> <441DEF97.2050108@nokia.com> <441ED3F2.2030108@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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: , Errors-To: simple-bounces@ietf.org inline ----- Original Message ----- From: "Paul Kyzivat" To: "Aki Niemi" Cc: "Miguel Garcia" ; "ext Adam Roach" ; Sent: Tuesday, March 21, 2006 12:10 AM Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt > > > Aki Niemi wrote: > >>>In other words, the nickname reservation protocol that you're defining >>>with the NICKNAME mechanism in MSRP shouldn't be limited to MSRP. My >>>suggestion, for what it's worth, is that you (1) split the nickname >>>reservation mechanism out into a separate draft, and (2) use either SIP >>>or the XCON Conference Control Protocol instead of MSRP. >> >> >> I think these two are actually reasonable suggestions, as long as the >> same disclaimer we have in the draft still holds (namely, scope it for a >> particular room only, first-come-first-served policy, defining "sticky" >> nicknames out-of-scope, etc.). > > I think it is ok if the mechanism doesn't require more than FCFS policy > for assignment of names. But neither should it be restricted to such a > policy. IMO sticky nicknames are quite important. It would be upsetting > if each time I came to the simple chat room I had to wonder whether > "fluffy" was still Cullen. > So, I suggest nickname should be register in chat room, then your nickname will not be stolen. If user come into chat room has not registered, server can assign default nickname to him. Xiao > 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 Mon Mar 20 15:34:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLR4w-0005kB-87; Mon, 20 Mar 2006 15:34:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLR4v-0005k6-3Y for simple@ietf.org; Mon, 20 Mar 2006 15:34:13 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLR4t-00024i-RT for simple@ietf.org; Mon, 20 Mar 2006 15:34:13 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 20 Mar 2006 12:34:11 -0800 X-IronPort-AV: i="4.03,112,1141632000"; d="scan'208"; a="262981149:sNHT30469838" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2KKY9Ym022263; Mon, 20 Mar 2006 12:34:11 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 15:34:12 -0500 Received: from [10.82.224.31] ([10.82.224.31]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 15:34:08 -0500 Message-ID: <441F11C0.80108@cisco.com> Date: Mon, 20 Mar 2006 15:34:08 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: smile Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt References: <43F07211.9040107@nokia.com> <441CA79C.4000708@nostrum.com> <441DEF97.2050108@nokia.com> <441ED3F2.2030108@cisco.com> <006001c64bcf$7316def0$cc838182@china.huawei.com> In-Reply-To: <006001c64bcf$7316def0$cc838182@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2006 20:34:09.0349 (UTC) FILETIME=[A3FBB750:01C64C5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Aki Niemi , 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: , Errors-To: simple-bounces@ietf.org smile wrote: >>I think it is ok if the mechanism doesn't require more than FCFS policy >>for assignment of names. But neither should it be restricted to such a >>policy. IMO sticky nicknames are quite important. It would be upsetting >>if each time I came to the simple chat room I had to wonder whether >>"fluffy" was still Cullen. > > So, I suggest nickname should be register in chat room, then your nickname > will not be stolen. If user come into chat room has not registered, server can > assign default nickname to him. I was asking that this behavior be *permitted* but not *required*. This is behavior I would desire from conference servers I deal with, but if some servers choose to support only FCFS then that is ok with me. (I will just try to avoid patronizing them.) Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 15:43:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLRDu-0004DF-Gr; Mon, 20 Mar 2006 15:43:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLRDt-0004DA-Qx for simple@ietf.org; Mon, 20 Mar 2006 15:43:29 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLRDs-0002G9-C9 for simple@ietf.org; Mon, 20 Mar 2006 15:43:29 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2KKhJ8a029540; Mon, 20 Mar 2006 22:43:22 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 22:43:19 +0200 Received: from [10.241.59.15] ([10.241.59.15]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Mar 2006 22:43:19 +0200 Message-ID: <441F13E4.1040408@nokia.com> Date: Mon, 20 Mar 2006 22:43:16 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Paul Kyzivat Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt References: <43F07211.9040107@nokia.com> <441CA79C.4000708@nostrum.com> <441DEF97.2050108@nokia.com> <441ED3F2.2030108@cisco.com> <006001c64bcf$7316def0$cc838182@china.huawei.com> <441F11C0.80108@cisco.com> In-Reply-To: <441F11C0.80108@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2006 20:43:19.0356 (UTC) FILETIME=[EBD01FC0:01C64C5E] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: simple-bounces@ietf.org ext Paul Kyzivat wrote: >> So, I suggest nickname should be register in chat room, then your >> nickname will not be stolen. If user come into chat room has not >> registered, server can assign default nickname to him. > > I was asking that this behavior be *permitted* but not *required*. This > is behavior I would desire from conference servers I deal with, but if > some servers choose to support only FCFS then that is ok with me. (I > will just try to avoid patronizing them.) Right. The current draft has this: Another option would be to use a nicknaming service, that allows allocating nickname URIs to users. Using such a URI in a conference in effect anonymizes the user, but still allows the user to be reached outside the chat room using the same identity. However, defining such nicknaming service machinery is out of the scope of this specification. ... In other words, a nickname is simply a username that is scoped for a particular chat room. Such nicknames are allocated on a first-come first-served policy, meaning they can also be "stolen". It is out of the scope of this specification to define nickname retention schemes, or nickaming services as discussed above. Is that sufficient? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 16:41:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLS7f-0001gS-0D; Mon, 20 Mar 2006 16:41:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLS7d-0001gN-Ej for simple@ietf.org; Mon, 20 Mar 2006 16:41:05 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLS7b-00059l-1D for simple@ietf.org; Mon, 20 Mar 2006 16:41:05 -0500 Received: from mail2.microsoft.com ([157.54.63.12]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 20 Mar 2006 13:41:02 -0800 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 13:41:01 -0800 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 13:41:01 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 13:41:00 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 13:40:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Mar 2006 13:41:01 -0800 Message-ID: <65F27F597EB1E44384BA802189D334C60A8428@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IM delivery reports for conferencing Thread-Index: AcZIek3x7vC60gqfR7y8eLfVaFZcnAD7Iovw From: "Sean Olson" To: "Hisham Khartabil" X-OriginalArrivalTime: 20 Mar 2006 21:40:57.0942 (UTC) FILETIME=[F94A7760:01C64C66] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: eburger@brooktrout.com, simple@ietf.org Subject: [Simple] RE: IM delivery reports for conferencing 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: , Errors-To: simple-bounces@ietf.org The URI attribute only works if you structure the rest of the information around it.... Are you suggesting aggregation by multipart MIME or creating a new top-level XML element?=20 -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Wednesday, March 15, 2006 1:49 PM To: Sean Olson Cc: eburger@brooktrout.com; simple@ietf.org Subject: Re: IM delivery reports for conferencing On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: > > Looking at: > http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts > -00.tx > t > And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt > > Neither seems to address the use case of an "exploder" or IM=20 > conferencing where a single IM may have multiple recipients. My=20 > suggestion is that the schema you choose for the notification allow=20 > multiple delivery notifications to be batched together with each entry > distringuished by the recipient URI. It does address it to an extent. That's what the "uri" attribute is there for. If we want to allow aggregation of receipts before sending the receipt to the IM sender, then we also need to start thinking about what the sender wants and how to indicate it in the IM itself. Hisham > > For example: > > For Draft-khartabil-simple-im-receipts-00 > > > 34jk324j > > read > 200 > The message has been read > > > error > 415 > The message could not be=20 > delivered > > > > Or, for Draft-burger-simple-imdn-03 > > > > 1542af3e8b@eburger@example.com > > > > im:hisham.khartabil@example.net > > read > > > > im:eric.burger@example.net > > read > > > > Sorry if this has been discussed before. Was there a reason this was=20 > omitted previously? > > Thanks, > Sean > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 16:51:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLSHW-0008UD-Tk; Mon, 20 Mar 2006 16:51:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLSHW-0008U7-5D for simple@ietf.org; Mon, 20 Mar 2006 16:51:18 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLSHT-0005L9-Cy for simple@ietf.org; Mon, 20 Mar 2006 16:51:18 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 635EC194488 for ; Mon, 20 Mar 2006 22:51:14 +0100 (CET) Received: from [130.129.134.123] ([130.129.134.123]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 22:49:32 +0100 In-Reply-To: <65F27F597EB1E44384BA802189D334C60A8428@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> References: <65F27F597EB1E44384BA802189D334C60A8428@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6a528758f7fc0374fb743737cb32509f@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Date: Mon, 20 Mar 2006 22:51:47 +0100 To: "Sean Olson" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 20 Mar 2006 21:49:32.0817 (UTC) FILETIME=[2C2E2810:01C64C68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: eburger@brooktrout.com, simple@ietf.org Subject: [Simple] Re: IM delivery reports for conferencing 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: , Errors-To: simple-bounces@ietf.org On Mar 20, 2006, at 10:41 PM, Sean Olson wrote: > The URI attribute only works if you structure the rest of the > information around it.... Are you suggesting aggregation by multipart > MIME or creating a new top-level XML element? I have suggested neither. I doesn't matter really although the latter makes more sense. The question is do we need such feature? and if we do, to allow the sender of the IM to choose which mode or reporting s/he wanted (aggregated or one by one)? If the answer to the first question is yes, then I strongly believe that the answer to the second question is also yes. Hisham > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Wednesday, March 15, 2006 1:49 PM > To: Sean Olson > Cc: eburger@brooktrout.com; simple@ietf.org > Subject: Re: IM delivery reports for conferencing > > > On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: > >> >> Looking at: >> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts >> -00.tx >> t >> And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt >> >> Neither seems to address the use case of an "exploder" or IM >> conferencing where a single IM may have multiple recipients. My >> suggestion is that the schema you choose for the notification allow >> multiple delivery notifications to be batched together with each entry > >> distringuished by the recipient URI. > > It does address it to an extent. That's what the "uri" attribute is > there for. If we want to allow aggregation of receipts before sending > the receipt to the IM sender, then we also need to start thinking about > what the sender wants and how to indicate it in the IM itself. > > Hisham > >> >> For example: >> >> For Draft-khartabil-simple-im-receipts-00 >> >> >> 34jk324j >> >> read >> 200 >> The message has been read >> >> >> error >> 415 >> The message could not be >> delivered >> >> >> >> Or, for Draft-burger-simple-imdn-03 >> >> >> >> 1542af3e8b@eburger@example.com >> >> >> >> im:hisham.khartabil@example.net >> >> read >> >> >> >> im:eric.burger@example.net >> >> read >> >> >> >> Sorry if this has been discussed before. Was there a reason this was >> omitted previously? >> >> Thanks, >> Sean >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 16:57:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLSNZ-0003CQ-Tu; Mon, 20 Mar 2006 16:57:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLSNZ-0003CL-5I for simple@ietf.org; Mon, 20 Mar 2006 16:57:33 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLSNY-0005dP-PL for simple@ietf.org; Mon, 20 Mar 2006 16:57:33 -0500 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 20 Mar 2006 13:57:32 -0800 Received: from tuk-hub-02.redmond.corp.microsoft.com ([157.54.70.28]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 13:57:31 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 13:57:31 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 13:57:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Mar 2006 13:57:33 -0800 Message-ID: <65F27F597EB1E44384BA802189D334C60A843C@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6a528758f7fc0374fb743737cb32509f@telio.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IM delivery reports for conferencing Thread-Index: AcZMaIwp+tCU0MRNToSgG8JDGluh4wAAHCFA From: "Sean Olson" To: "Hisham Khartabil" X-OriginalArrivalTime: 20 Mar 2006 21:57:28.0905 (UTC) FILETIME=[47F36B90:01C64C69] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: eburger@brooktrout.com, simple@ietf.org Subject: [Simple] RE: IM delivery reports for conferencing 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: , Errors-To: simple-bounces@ietf.org Well, my opinion obviously is that we do need this capability. However, I don't believe the sender should really be in control of this facet of delivery notifications. In fact if you build in aggregation support now rather than later, than you don't even need to negotiate this. (I propose making receiving aggregated DN support at the sender mandatory)=20 -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Monday, March 20, 2006 1:52 PM To: Sean Olson Cc: eburger@brooktrout.com; simple@ietf.org Subject: Re: IM delivery reports for conferencing On Mar 20, 2006, at 10:41 PM, Sean Olson wrote: > The URI attribute only works if you structure the rest of the=20 > information around it.... Are you suggesting aggregation by multipart=20 > MIME or creating a new top-level XML element? I have suggested neither. I doesn't matter really although the latter makes more sense. The question is do we need such feature? and if we do, to allow the sender of the IM to choose which mode or reporting s/he wanted (aggregated or one by one)? If the answer to the first question is yes, then I strongly believe that the answer to the second question is also yes. Hisham > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Wednesday, March 15, 2006 1:49 PM > To: Sean Olson > Cc: eburger@brooktrout.com; simple@ietf.org > Subject: Re: IM delivery reports for conferencing > > > On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: > >> >> Looking at: >> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts >> -00.tx >> t >> And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt >> >> Neither seems to address the use case of an "exploder" or IM=20 >> conferencing where a single IM may have multiple recipients. My=20 >> suggestion is that the schema you choose for the notification allow=20 >> multiple delivery notifications to be batched together with each=20 >> entry > >> distringuished by the recipient URI. > > It does address it to an extent. That's what the "uri" attribute is=20 > there for. If we want to allow aggregation of receipts before sending=20 > the receipt to the IM sender, then we also need to start thinking=20 > about what the sender wants and how to indicate it in the IM itself. > > Hisham > >> >> For example: >> >> For Draft-khartabil-simple-im-receipts-00 >> >> >> 34jk324j >> >> read >> 200 >> The message has been read >> >> >> error >> 415 >> The message could not be=20 >> delivered >> >> >> >> Or, for Draft-burger-simple-imdn-03 >> >> >> >> 1542af3e8b@eburger@example.com >> >> >> >> im:hisham.khartabil@example.net >> >> read >> >> >> >> im:eric.burger@example.net >> >> read >> >> >> >> Sorry if this has been discussed before. Was there a reason this was=20 >> omitted previously? >> >> Thanks, >> Sean >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 20 20:54:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLW5A-0006D2-Rf; Mon, 20 Mar 2006 20:54:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLW5A-0006Cx-B2 for simple@ietf.org; Mon, 20 Mar 2006 20:54:48 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLW5A-0007VB-3w for simple@ietf.org; Mon, 20 Mar 2006 20:54:48 -0500 X-IronPort-AV: i="4.03,112,1141621200"; d="scan'208"; a="30326041:sNHT44660520" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Mar 2006 20:54:46 -0500 Message-ID: <330A23D8336C0346B5C1A5BB19666647027B03BD@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSRP chat and IMDN Thread-Index: AcZMA+8rJ+/bOOEdTxewnrF/7BQ3zQAhjS6Q From: "Burger, Eric" To: "Jussi K. Virtanen" , "Miguel Garcia" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IETF SIMPLE Subject: [Simple] RE: MSRP chat and IMDN 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: , Errors-To: simple-bounces@ietf.org That was in -00 of IMDN. -----Original Message----- From: Jussi K. Virtanen [mailto:jussi.k.virtanen@gmail.com]=20 Sent: Monday, March 20, 2006 4:50 AM To: Miguel Garcia Cc: Burger, Eric; Hisham Khartabil; IETF SIMPLE Subject: Re: MSRP chat and IMDN Hi Miguel, On 2006-03-20, Miguel Garcia wrote: > I agree that at some point in time we need to synchronize > MSRP chat with IMDN, and it is not our intention to specify > a mechanism if we can reuse IMDN. > BUT: draft-burger-simple-imdn-03 does not provide a mechanism > to inform whether a message has been delivered or not, instead, > the draft relies on the protocol (MSRP). Instead, > draft-khartabil-simple-im-receipts-00 provides a mechanism for > delivery receipt. So, depending on what the final IMDN mechanism > is able to provide, we will need or not to extend MSRP. Couldn't the "first-recipient" mechanism of IMDN, described in Section 9.3.1 of draft-burger-simple-imdn-03, be extended from B2BUAs to MSRP switches as well? An excerpt from the section: o If the B2BUA forwards the message, it SHOULD return an "processed" IMDN, mindful of the privacy considerations enumerated in Section 4. o If there was an error processing the message, the B2BUA SHOULD return an "error" IMDN, mindful of the privacy considerations enumerated in Section 4. I believe an "error" IMDN could be a substitute for a 427 response. draft-khartabil-simple-im-receipts-00 explicitly prohibits requests of delivery receipts for messages that are transferred on top of MSRP (Section 7.1.1.). I see that as a problem because the delivery status in MSRP is bound to an MSRP session but one CPIM message can traverse on its way over multiple MSRP sessions, as it does in MSRP chat (draft-niemi-simple-chat-04). BR, -- Jussi K. Virtanen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 21 03:15:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLc1y-00078W-2d; Tue, 21 Mar 2006 03:15:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLc1w-00078R-QS for simple@ietf.org; Tue, 21 Mar 2006 03:15:52 -0500 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLc1v-0003Ql-8c for simple@ietf.org; Tue, 21 Mar 2006 03:15:52 -0500 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] Filtering: one issue still open Date: Tue, 21 Mar 2006 09:15:46 +0100 Message-ID: <3ACC9A25264A684F82C71840111F979801463B2D@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Filtering: one issue still open Thread-Index: AcZMPt6J2ujfwLu1TLi9f4L+pBkkLQAgFRdA From: To: , X-OriginalArrivalTime: 21 Mar 2006 08:15:49.0669 (UTC) FILETIME=[A9BABD50:01C64CBF] X-Spam-Score: 0.2 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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: , Errors-To: simple-bounces@ietf.org Hi,=20 I am still not sure what the "previous XML document" is. Is it the last one which reached the watcher, or the last one selected to be delivered by the trigger? As michal wrote, due to throtlling, these might not be the same. Thank you,=20 Silvestr > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Monday, March 20, 2006 5:53 PM > To: Burda Michal > Cc: simple@ietf.org > Subject: Re: [Simple] Filtering: one issue still open >=20 >=20 > On Mar 20, 2006, at 3:41 PM, wrote: >=20 > > Hi, > > > > draft-ietf-simple-filter-format-05 says: > > > > "The (filter's) element is used to identify the XML element > > or > > attribute, from the package specific XML document, whose value MUST > > change, compared to the "previous XML document", in order to activate > > the trigger and cause the content to be delivered. Previous XML > > document in this context refers to the last XML document that was > > selected for delivery to that specific subscription before any filter > > was applied to it." > > > > I understand that the "previous XML document" is the last notification > > that is sent to the subscriber, but without any 'what' filter applied > > on > > it. Simply said, the "previous XML document" is the whole presentity's > > presence document whose filtered piece was selected for delivery to the > > subscriber. Right? >=20 > This is right. >=20 > > > > Now, I don't completely understand, what is "selected for delivery". Is > > it the information that passed the triggering only, or is it the > > information that was *really* sent to the subscriber? It is not the > > same, since after filtering, there is also the throttling component in > > the presence server that may cause the notification to be not sent, in > > fact. >=20 > I will reword this sentence in the Author's 48 hours since it is > causing a lot of confusion. What you describe as the "previous XML > document" is enough. >=20 > Hisham >=20 > > > > Please note, this is also connected to the filtering & throttling > > paradox I've posted here a few days ago. > > > > What is your opinion Hisham? (Other people are welcome to post > > suggestions too, of course :) > > > > Thank you very much. > > > > > > Best regards, > > > > > > Michal Burda > > > > _______________________________________________ > > 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 21 07:34:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLg3s-0001Y1-1B; Tue, 21 Mar 2006 07:34:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLg3r-0001Xh-7w for simple@ietf.org; Tue, 21 Mar 2006 07:34:07 -0500 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLg3q-0005mg-Md for simple@ietf.org; Tue, 21 Mar 2006 07:34:07 -0500 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] problem with filters and resource lists Date: Tue, 21 Mar 2006 13:34:02 +0100 Message-ID: <3ACC9A25264A684F82C71840111F979801463DAB@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] problem with filters and resource lists Thread-Index: AcYwsDZqiUlKx4BySOqj/HePVKHZDAcMku0w From: To: X-OriginalArrivalTime: 21 Mar 2006 12:34:05.0080 (UTC) FILETIME=[BDB6D180:01C64CE3] X-Spam-Score: 0.2 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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: , Errors-To: simple-bounces@ietf.org Hello,=20 After some deeper analysis it seems to me that it would be better if the resource specific filters overrides the list specific filter. Example: I have list of friends, and I want to be notified about changes in status in tuple A. So I create filter without uri, and every resource is filtered. Then I want to set another filter for one resource. To achieve it, I must remove the list specific filter, and create resource specific filters for each resource. So if I have 10 resources, there will be 10 filters. On the other hand, if the resource specific filter overrides the list specific one, I would just add one resource specific filter. I have only 2 filters instead of 10. What is your opinion? Silvestr > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Monday, February 13, 2006 4:15 PM > To: Peknik Silvestr > Cc: simple@ietf.org > Subject: Re: [Simple] problem with filters and resource lists >=20 >=20 > On Feb 13, 2006, at 3:13 PM, wrote: >=20 > > Hello, > > > > I found another thing I need help with. > > > > 3.3 (draft-ietf-simple-event-filter-funct-05): > > ... > > A SUBSCRIBE request destined to a list URI [4] MAY include multiple > > filters specific to individual resources. This is achieved by > > including multiple elements with different URIs of > > resources > > in each of those elements. This resource specific filter overrides > > any list specific filter, if any. The list specific filter may or > > may not include a URI. > > > > So I guess the filters do not stack. If I have filter without uri and > > another one with particular uri, only the one with particular uri is > > applied to the affected resource. Right? >=20 > Not quite. The text should be interpreted as saying that the individual > resource specific filter is applied first. >=20 > > > > Now consider following situation. I have list1@1.com (RLS1) and > > list2@2.com (RLS2). List2 is one of the resources in list1. List2 > > contains bob@1.com. A subscription to list1 carries filters for bob > > (F1) > > and for list2 (F2). F2 is propagated to the subscription to list2. RLS2 > > subscribes back to RLS1 to bob and propagates F2. >=20 > Why is F2 being propagated? >=20 > Hisham >=20 > > So notifications from > > bob are filtered with both F2 (because it is propagated) and with F1 > > because bob is under RLS1 administrative control and thus RLS has to > > filter the notifications. > > > > Should it work this way? > > > > Thank you, > > > > Silvestr Peknik > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 21 09:55:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiGR-00057s-Th; Tue, 21 Mar 2006 09:55:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiGQ-00055h-GR for simple@ietf.org; Tue, 21 Mar 2006 09:55:14 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLiGP-0002Yw-Qu for simple@ietf.org; Tue, 21 Mar 2006 09:55:14 -0500 Received: from mail2.microsoft.com ([157.54.63.12]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 21 Mar 2006 06:55:13 -0800 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 06:55:12 -0800 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 06:55:12 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 06:55:12 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 06:55:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Mar 2006 06:55:13 -0800 Message-ID: <65F27F597EB1E44384BA802189D334C60A864F@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <330A23D8336C0346B5C1A5BB19666647027B03BA@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IM delivery reports for conferencing Thread-Index: AcZMaIwp+tCU0MRNToSgG8JDGluh4wAAHCFAAAhAqLAAG1hkEA== From: "Sean Olson" To: "Burger, Eric" , "Hisham Khartabil" X-OriginalArrivalTime: 21 Mar 2006 14:55:08.0774 (UTC) FILETIME=[72780860:01C64CF7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: simple@ietf.org Subject: [Simple] RE: IM delivery reports for conferencing 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: , Errors-To: simple-bounces@ietf.org Caring about notifications is one thing .... Caring whether they are batched together or not is another. The second should be in the control of the server=20 -----Original Message----- From: Burger, Eric [mailto:EBurger@cantata.com]=20 Sent: Monday, March 20, 2006 5:52 PM To: Sean Olson; Hisham Khartabil Cc: simple@ietf.org Subject: RE: IM delivery reports for conferencing I would offer that it MUST be driven by the client - they are the only one that knows whether they care. C.f. the use of notifications for MSRP conferencing. -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Monday, March 20, 2006 4:58 PM To: Hisham Khartabil Cc: Burger, Eric; simple@ietf.org Subject: RE: IM delivery reports for conferencing Well, my opinion obviously is that we do need this capability. However, I don't believe the sender should really be in control of this facet of delivery notifications. In fact if you build in aggregation support now rather than later, than you don't even need to negotiate this. (I propose making receiving aggregated DN support at the sender mandatory)=20 -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] Sent: Monday, March 20, 2006 1:52 PM To: Sean Olson Cc: eburger@brooktrout.com; simple@ietf.org Subject: Re: IM delivery reports for conferencing On Mar 20, 2006, at 10:41 PM, Sean Olson wrote: > The URI attribute only works if you structure the rest of the=20 > information around it.... Are you suggesting aggregation by multipart=20 > MIME or creating a new top-level XML element? I have suggested neither. I doesn't matter really although the latter makes more sense. The question is do we need such feature? and if we do, to allow the sender of the IM to choose which mode or reporting s/he wanted (aggregated or one by one)? If the answer to the first question is yes, then I strongly believe that the answer to the second question is also yes. Hisham > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Wednesday, March 15, 2006 1:49 PM > To: Sean Olson > Cc: eburger@brooktrout.com; simple@ietf.org > Subject: Re: IM delivery reports for conferencing > > > On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: > >> >> Looking at: >> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts >> -00.tx >> t >> And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt >> >> Neither seems to address the use case of an "exploder" or IM=20 >> conferencing where a single IM may have multiple recipients. My=20 >> suggestion is that the schema you choose for the notification allow=20 >> multiple delivery notifications to be batched together with each=20 >> entry > >> distringuished by the recipient URI. > > It does address it to an extent. That's what the "uri" attribute is=20 > there for. If we want to allow aggregation of receipts before sending=20 > the receipt to the IM sender, then we also need to start thinking=20 > about what the sender wants and how to indicate it in the IM itself. > > Hisham > >> >> For example: >> >> For Draft-khartabil-simple-im-receipts-00 >> >> >> 34jk324j >> >> read >> 200 >> The message has been read >> >> >> error >> 415 >> The message could not be=20 >> delivered >> >> >> >> Or, for Draft-burger-simple-imdn-03 >> >> >> >> 1542af3e8b@eburger@example.com >> >> >> >> im:hisham.khartabil@example.net >> >> read >> >> >> >> im:eric.burger@example.net >> >> read >> >> >> >> Sorry if this has been discussed before. Was there a reason this was=20 >> omitted previously? >> >> Thanks, >> Sean >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 21 10:00:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiLT-0007Cz-Hj; Tue, 21 Mar 2006 10:00:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiLS-0007Cu-Jt for simple@ietf.org; Tue, 21 Mar 2006 10:00:26 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLiLS-0002iA-Aq for simple@ietf.org; Tue, 21 Mar 2006 10:00:26 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 21 Mar 2006 07:00:27 -0800 X-IronPort-AV: i="4.03,114,1141632000"; d="scan'208"; a="263206998:sNHT30396244" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2LF0PYg005709 for ; Tue, 21 Mar 2006 07:00:25 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 07:00:25 -0800 Received: from [130.129.128.208] ([10.89.20.121]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 07:00:25 -0800 Message-ID: <44201508.1010107@cisco.com> Date: Tue, 21 Mar 2006 10:00:24 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 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-OriginalArrivalTime: 21 Mar 2006 15:00:25.0363 (UTC) FILETIME=[2F2BAE30:01C64CF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Simple] comments on draft-mahy-simple-xcap-profile-01 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: , Errors-To: simple-bounces@ietf.org This draft is much improved from the previous version, and I'm pretty comfortable with the ideas in the document. Some specific comments below. Firstly, I think that the document is best viewed as a profile of the two application usages under discussion, rather than a profile of xcap itself. None of the concepts in the document would apply to a different application usage which didn't have specific common places in the document where changes were expected. Secondly, on the server validation - I don't think what you describe will work, because the enclosing header and footers won't have namespace declarations for the prefixes that are in scope at the point of actual insertion. I'd suggest basically using the XML fragment specification to construct a wrapper, as it will have the enclosing namespace declarations. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 21 10:49:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLj6w-0000SF-Cp; Tue, 21 Mar 2006 10:49:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLj6v-0000OH-7L for simple@ietf.org; Tue, 21 Mar 2006 10:49:29 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLj6u-0004fi-FL for simple@ietf.org; Tue, 21 Mar 2006 10:49:29 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 22F8719448C for ; Tue, 21 Mar 2006 16:49:27 +0100 (CET) Received: from [130.129.134.123] ([130.129.134.123]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 16:47:45 +0100 In-Reply-To: <65F27F597EB1E44384BA802189D334C60A864F@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> References: <65F27F597EB1E44384BA802189D334C60A864F@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Date: Tue, 21 Mar 2006 16:50:00 +0100 To: "Sean Olson" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 21 Mar 2006 15:47:45.0401 (UTC) FILETIME=[CBF71690:01C64CFE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: simple@ietf.org, "Burger, Eric" Subject: [Simple] Re: IM delivery reports for conferencing 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: , Errors-To: simple-bounces@ietf.org I, for one, want such control. I would like to choose if I want one receipt per user whenever each individual reads the IM or I want to wait until all recipients have read the IM before I am notified. Hisham On Mar 21, 2006, at 3:55 PM, Sean Olson wrote: > Caring about notifications is one thing .... Caring whether they are > batched together or not is another. The second should be in the control > of the server > > -----Original Message----- > From: Burger, Eric [mailto:EBurger@cantata.com] > Sent: Monday, March 20, 2006 5:52 PM > To: Sean Olson; Hisham Khartabil > Cc: simple@ietf.org > Subject: RE: IM delivery reports for conferencing > > I would offer that it MUST be driven by the client - they are the only > one that knows whether they care. C.f. the use of notifications for > MSRP conferencing. > > -----Original Message----- > From: Sean Olson [mailto:Sean.Olson@microsoft.com] > Sent: Monday, March 20, 2006 4:58 PM > To: Hisham Khartabil > Cc: Burger, Eric; simple@ietf.org > Subject: RE: IM delivery reports for conferencing > > Well, my opinion obviously is that we do need this capability. However, > I don't believe the sender should really be in control of this facet of > delivery notifications. In fact if you build in aggregation support now > rather than later, than you don't even need to negotiate this. (I > propose making receiving aggregated DN support at the sender mandatory) > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Monday, March 20, 2006 1:52 PM > To: Sean Olson > Cc: eburger@brooktrout.com; simple@ietf.org > Subject: Re: IM delivery reports for conferencing > > > On Mar 20, 2006, at 10:41 PM, Sean Olson wrote: > >> The URI attribute only works if you structure the rest of the >> information around it.... Are you suggesting aggregation by multipart >> MIME or creating a new top-level XML element? > > I have suggested neither. I doesn't matter really although the latter > makes more sense. The question is do we need such feature? and if we > do, > to allow the sender of the IM to choose which mode or reporting s/he > wanted (aggregated or one by one)? If the answer to the first question > is yes, then I strongly believe that the answer to the second question > is also yes. > > Hisham > >> >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Wednesday, March 15, 2006 1:49 PM >> To: Sean Olson >> Cc: eburger@brooktrout.com; simple@ietf.org >> Subject: Re: IM delivery reports for conferencing >> >> >> On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: >> >>> >>> Looking at: >>> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts >>> -00.tx >>> t >>> And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt >>> >>> Neither seems to address the use case of an "exploder" or IM >>> conferencing where a single IM may have multiple recipients. My >>> suggestion is that the schema you choose for the notification allow >>> multiple delivery notifications to be batched together with each >>> entry >> >>> distringuished by the recipient URI. >> >> It does address it to an extent. That's what the "uri" attribute is >> there for. If we want to allow aggregation of receipts before sending >> the receipt to the IM sender, then we also need to start thinking >> about what the sender wants and how to indicate it in the IM itself. >> >> Hisham >> >>> >>> For example: >>> >>> For Draft-khartabil-simple-im-receipts-00 >>> >>> >>> 34jk324j >>> >>> read >>> 200 >>> The message has been read >>> >>> >>> error >>> 415 >>> The message could not be >>> delivered >>> >>> >>> >>> Or, for Draft-burger-simple-imdn-03 >>> >>> >>> >>> 1542af3e8b@eburger@example.com >>> >>> >>> >>> im:hisham.khartabil@example.net >>> >>> read >>> >>> >>> >>> im:eric.burger@example.net >>> >>> read >>> >>> >>> >>> Sorry if this has been discussed before. Was there a reason this was >>> omitted previously? >>> >>> Thanks, >>> Sean >>> >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 21 10:53:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjB5-00034S-98; Tue, 21 Mar 2006 10:53:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjB4-00033h-2K for simple@ietf.org; Tue, 21 Mar 2006 10:53:46 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjB3-0004uR-Iv for simple@ietf.org; Tue, 21 Mar 2006 10:53:46 -0500 Received: from mail1.microsoft.com ([157.54.63.55]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 21 Mar 2006 07:53:44 -0800 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 07:53:44 -0800 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 07:53:44 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 07:53:44 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 07:53:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Mar 2006 07:53:44 -0800 Message-ID: <65F27F597EB1E44384BA802189D334C60A8675@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IM delivery reports for conferencing Thread-Index: AcZM/whqz35FjWI+RxSJ/RdksjbvEgAADXvA From: "Sean Olson" To: "Hisham Khartabil" X-OriginalArrivalTime: 21 Mar 2006 15:53:40.0698 (UTC) FILETIME=[9FBD1BA0:01C64CFF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: simple@ietf.org, "Burger, Eric" Subject: [Simple] RE: IM delivery reports for conferencing 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: , Errors-To: simple-bounces@ietf.org What I'm proposing is that the server has the ability to batch. This may mean the server sends one receipt per recipient or one batched receipt or even multiple batched receipts. Batching does not have to mean that you wait until all clients respond. More to the point, I would not presume any guarantee of time for the server to send the delivery notifications. Under load, the server may chose to prioritize the messages themselves over the delivery notifications and therefore delay the IMDNs. =20 -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Tuesday, March 21, 2006 7:50 AM To: Sean Olson Cc: Burger, Eric; simple@ietf.org Subject: Re: IM delivery reports for conferencing I, for one, want such control. I would like to choose if I want one receipt per user whenever each individual reads the IM or I want to wait until all recipients have read the IM before I am notified. Hisham On Mar 21, 2006, at 3:55 PM, Sean Olson wrote: > Caring about notifications is one thing .... Caring whether they are=20 > batched together or not is another. The second should be in the=20 > control of the server > > -----Original Message----- > From: Burger, Eric [mailto:EBurger@cantata.com] > Sent: Monday, March 20, 2006 5:52 PM > To: Sean Olson; Hisham Khartabil > Cc: simple@ietf.org > Subject: RE: IM delivery reports for conferencing > > I would offer that it MUST be driven by the client - they are the only > one that knows whether they care. C.f. the use of notifications for=20 > MSRP conferencing. > > -----Original Message----- > From: Sean Olson [mailto:Sean.Olson@microsoft.com] > Sent: Monday, March 20, 2006 4:58 PM > To: Hisham Khartabil > Cc: Burger, Eric; simple@ietf.org > Subject: RE: IM delivery reports for conferencing > > Well, my opinion obviously is that we do need this capability.=20 > However, I don't believe the sender should really be in control of=20 > this facet of delivery notifications. In fact if you build in=20 > aggregation support now rather than later, than you don't even need to > negotiate this. (I propose making receiving aggregated DN support at=20 > the sender mandatory) > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Monday, March 20, 2006 1:52 PM > To: Sean Olson > Cc: eburger@brooktrout.com; simple@ietf.org > Subject: Re: IM delivery reports for conferencing > > > On Mar 20, 2006, at 10:41 PM, Sean Olson wrote: > >> The URI attribute only works if you structure the rest of the=20 >> information around it.... Are you suggesting aggregation by multipart >> MIME or creating a new top-level XML element? > > I have suggested neither. I doesn't matter really although the latter=20 > makes more sense. The question is do we need such feature? and if we=20 > do, to allow the sender of the IM to choose which mode or reporting=20 > s/he wanted (aggregated or one by one)? If the answer to the first=20 > question is yes, then I strongly believe that the answer to the second > question is also yes. > > Hisham > >> >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Wednesday, March 15, 2006 1:49 PM >> To: Sean Olson >> Cc: eburger@brooktrout.com; simple@ietf.org >> Subject: Re: IM delivery reports for conferencing >> >> >> On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: >> >>> >>> Looking at: >>> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts >>> -00.tx >>> t >>> And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt >>> >>> Neither seems to address the use case of an "exploder" or IM=20 >>> conferencing where a single IM may have multiple recipients. My=20 >>> suggestion is that the schema you choose for the notification allow=20 >>> multiple delivery notifications to be batched together with each=20 >>> entry >> >>> distringuished by the recipient URI. >> >> It does address it to an extent. That's what the "uri" attribute is=20 >> there for. If we want to allow aggregation of receipts before sending >> the receipt to the IM sender, then we also need to start thinking=20 >> about what the sender wants and how to indicate it in the IM itself. >> >> Hisham >> >>> >>> For example: >>> >>> For Draft-khartabil-simple-im-receipts-00 >>> >>> >>> 34jk324j >>> >>> read >>> 200 >>> The message has been read >>> >>> >>> error >>> 415 >>> The message could not be=20 >>> delivered >>> >>> >>> >>> Or, for Draft-burger-simple-imdn-03 >>> >>> >>> >>> 1542af3e8b@eburger@example.com >>> >>> >>> >>> im:hisham.khartabil@example.net >>> >>> read >>> >>> >>> >>> im:eric.burger@example.net >>> >>> read >>> >>> >>> >>> Sorry if this has been discussed before. Was there a reason this was >>> omitted previously? >>> >>> Thanks, >>> Sean >>> >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 21 11:37:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjri-0004yg-8E; Tue, 21 Mar 2006 11:37:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjrh-0004yb-6o for simple@ietf.org; Tue, 21 Mar 2006 11:37:49 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjrg-0006lE-QC for simple@ietf.org; Tue, 21 Mar 2006 11:37:49 -0500 X-IronPort-AV: i="4.03,115,1141621200"; d="scan'208"; a="30355233:sNHT83050556" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Mar 2006 11:37:46 -0500 Message-ID: <330A23D8336C0346B5C1A5BB19666647027B0830@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IM delivery reports for conferencing Thread-Index: AcZMaIwp+tCU0MRNToSgG8JDGluh4wAAHCFAAAhAqLAAG1hkEAADi+GA From: "Burger, Eric" To: "Sean Olson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: simple@ietf.org Subject: [Simple] RE: IM delivery reports for conferencing 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: , Errors-To: simple-bounces@ietf.org I could argue that it is both: the sender might want individual reports; the server, under any circumstance, would rather not batch. Batching would be (should be?) an enhanced, extra cost service, as it imposes a bunch of processing and storage requirements on the server. -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com]=20 Sent: Tuesday, March 21, 2006 9:55 AM To: Burger, Eric; Hisham Khartabil Cc: simple@ietf.org Subject: RE: IM delivery reports for conferencing Caring about notifications is one thing .... Caring whether they are batched together or not is another. The second should be in the control of the server=20 -----Original Message----- From: Burger, Eric [mailto:EBurger@cantata.com]=20 Sent: Monday, March 20, 2006 5:52 PM To: Sean Olson; Hisham Khartabil Cc: simple@ietf.org Subject: RE: IM delivery reports for conferencing I would offer that it MUST be driven by the client - they are the only one that knows whether they care. C.f. the use of notifications for MSRP conferencing. -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Monday, March 20, 2006 4:58 PM To: Hisham Khartabil Cc: Burger, Eric; simple@ietf.org Subject: RE: IM delivery reports for conferencing Well, my opinion obviously is that we do need this capability. However, I don't believe the sender should really be in control of this facet of delivery notifications. In fact if you build in aggregation support now rather than later, than you don't even need to negotiate this. (I propose making receiving aggregated DN support at the sender mandatory)=20 -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] Sent: Monday, March 20, 2006 1:52 PM To: Sean Olson Cc: eburger@brooktrout.com; simple@ietf.org Subject: Re: IM delivery reports for conferencing On Mar 20, 2006, at 10:41 PM, Sean Olson wrote: > The URI attribute only works if you structure the rest of the=20 > information around it.... Are you suggesting aggregation by multipart=20 > MIME or creating a new top-level XML element? I have suggested neither. I doesn't matter really although the latter makes more sense. The question is do we need such feature? and if we do, to allow the sender of the IM to choose which mode or reporting s/he wanted (aggregated or one by one)? If the answer to the first question is yes, then I strongly believe that the answer to the second question is also yes. Hisham > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Wednesday, March 15, 2006 1:49 PM > To: Sean Olson > Cc: eburger@brooktrout.com; simple@ietf.org > Subject: Re: IM delivery reports for conferencing > > > On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: > >> >> Looking at: >> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts >> -00.tx >> t >> And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt >> >> Neither seems to address the use case of an "exploder" or IM=20 >> conferencing where a single IM may have multiple recipients. My=20 >> suggestion is that the schema you choose for the notification allow=20 >> multiple delivery notifications to be batched together with each=20 >> entry > >> distringuished by the recipient URI. > > It does address it to an extent. That's what the "uri" attribute is=20 > there for. If we want to allow aggregation of receipts before sending=20 > the receipt to the IM sender, then we also need to start thinking=20 > about what the sender wants and how to indicate it in the IM itself. > > Hisham > >> >> For example: >> >> For Draft-khartabil-simple-im-receipts-00 >> >> >> 34jk324j >> >> read >> 200 >> The message has been read >> >> >> error >> 415 >> The message could not be=20 >> delivered >> >> >> >> Or, for Draft-burger-simple-imdn-03 >> >> >> >> 1542af3e8b@eburger@example.com >> >> >> >> im:hisham.khartabil@example.net >> >> read >> >> >> >> im:eric.burger@example.net >> >> read >> >> >> >> Sorry if this has been discussed before. Was there a reason this was=20 >> omitted previously? >> >> Thanks, >> Sean >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 21 11:39:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjtb-0005Xl-Ot; Tue, 21 Mar 2006 11:39:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjtZ-0005Xc-Vq for simple@ietf.org; Tue, 21 Mar 2006 11:39:45 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjtY-0006qB-IS for simple@ietf.org; Tue, 21 Mar 2006 11:39:45 -0500 X-IronPort-AV: i="4.03,115,1141621200"; d="scan'208"; a="30355316:sNHT61853712" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Mar 2006 11:39:43 -0500 Message-ID: <330A23D8336C0346B5C1A5BB19666647027B083F@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IM delivery reports for conferencing Thread-Index: AcZM/whqz35FjWI+RxSJ/RdksjbvEgAADXvAAAGpODA= From: "Burger, Eric" To: "Sean Olson" , "Hisham Khartabil" X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: simple@ietf.org Subject: [Simple] RE: IM delivery reports for conferencing 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: , Errors-To: simple-bounces@ietf.org The behaviour described below, with the exception of partial batches, was all in -00. I would offer metering the responses is purely an implementation issue.=20 -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com]=20 Sent: Tuesday, March 21, 2006 10:54 AM To: Hisham Khartabil Cc: Burger, Eric; simple@ietf.org Subject: RE: IM delivery reports for conferencing What I'm proposing is that the server has the ability to batch. This may mean the server sends one receipt per recipient or one batched receipt or even multiple batched receipts. Batching does not have to mean that you wait until all clients respond. More to the point, I would not presume any guarantee of time for the server to send the delivery notifications. Under load, the server may chose to prioritize the messages themselves over the delivery notifications and therefore delay the IMDNs. =20 -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Tuesday, March 21, 2006 7:50 AM To: Sean Olson Cc: Burger, Eric; simple@ietf.org Subject: Re: IM delivery reports for conferencing I, for one, want such control. I would like to choose if I want one receipt per user whenever each individual reads the IM or I want to wait until all recipients have read the IM before I am notified. Hisham On Mar 21, 2006, at 3:55 PM, Sean Olson wrote: > Caring about notifications is one thing .... Caring whether they are=20 > batched together or not is another. The second should be in the=20 > control of the server > > -----Original Message----- > From: Burger, Eric [mailto:EBurger@cantata.com] > Sent: Monday, March 20, 2006 5:52 PM > To: Sean Olson; Hisham Khartabil > Cc: simple@ietf.org > Subject: RE: IM delivery reports for conferencing > > I would offer that it MUST be driven by the client - they are the only > one that knows whether they care. C.f. the use of notifications for=20 > MSRP conferencing. > > -----Original Message----- > From: Sean Olson [mailto:Sean.Olson@microsoft.com] > Sent: Monday, March 20, 2006 4:58 PM > To: Hisham Khartabil > Cc: Burger, Eric; simple@ietf.org > Subject: RE: IM delivery reports for conferencing > > Well, my opinion obviously is that we do need this capability.=20 > However, I don't believe the sender should really be in control of=20 > this facet of delivery notifications. In fact if you build in=20 > aggregation support now rather than later, than you don't even need to > negotiate this. (I propose making receiving aggregated DN support at=20 > the sender mandatory) > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Monday, March 20, 2006 1:52 PM > To: Sean Olson > Cc: eburger@brooktrout.com; simple@ietf.org > Subject: Re: IM delivery reports for conferencing > > > On Mar 20, 2006, at 10:41 PM, Sean Olson wrote: > >> The URI attribute only works if you structure the rest of the=20 >> information around it.... Are you suggesting aggregation by multipart >> MIME or creating a new top-level XML element? > > I have suggested neither. I doesn't matter really although the latter=20 > makes more sense. The question is do we need such feature? and if we=20 > do, to allow the sender of the IM to choose which mode or reporting=20 > s/he wanted (aggregated or one by one)? If the answer to the first=20 > question is yes, then I strongly believe that the answer to the second > question is also yes. > > Hisham > >> >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Wednesday, March 15, 2006 1:49 PM >> To: Sean Olson >> Cc: eburger@brooktrout.com; simple@ietf.org >> Subject: Re: IM delivery reports for conferencing >> >> >> On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: >> >>> >>> Looking at: >>> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts >>> -00.tx >>> t >>> And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt >>> >>> Neither seems to address the use case of an "exploder" or IM=20 >>> conferencing where a single IM may have multiple recipients. My=20 >>> suggestion is that the schema you choose for the notification allow=20 >>> multiple delivery notifications to be batched together with each=20 >>> entry >> >>> distringuished by the recipient URI. >> >> It does address it to an extent. That's what the "uri" attribute is=20 >> there for. If we want to allow aggregation of receipts before sending >> the receipt to the IM sender, then we also need to start thinking=20 >> about what the sender wants and how to indicate it in the IM itself. >> >> Hisham >> >>> >>> For example: >>> >>> For Draft-khartabil-simple-im-receipts-00 >>> >>> >>> 34jk324j >>> >>> read >>> 200 >>> The message has been read >>> >>> >>> error >>> 415 >>> The message could not be=20 >>> delivered >>> >>> >>> >>> Or, for Draft-burger-simple-imdn-03 >>> >>> >>> >>> 1542af3e8b@eburger@example.com >>> >>> >>> >>> im:hisham.khartabil@example.net >>> >>> read >>> >>> >>> >>> im:eric.burger@example.net >>> >>> read >>> >>> >>> >>> Sorry if this has been discussed before. Was there a reason this was >>> omitted previously? >>> >>> Thanks, >>> Sean >>> >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 21 11:41:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjuk-0005yx-RA; Tue, 21 Mar 2006 11:40:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjuj-0005ye-Rf for simple@ietf.org; Tue, 21 Mar 2006 11:40:57 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjuh-0006sV-8i for simple@ietf.org; Tue, 21 Mar 2006 11:40:57 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 21 Mar 2006 08:40:54 -0800 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 08:40:54 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 08:40:51 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 08:40:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Mar 2006 08:40:50 -0800 Message-ID: <65F27F597EB1E44384BA802189D334C60A868C@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <330A23D8336C0346B5C1A5BB19666647027B0830@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IM delivery reports for conferencing Thread-Index: AcZMaIwp+tCU0MRNToSgG8JDGluh4wAAHCFAAAhAqLAAG1hkEAADi+GAAAAchgA= From: "Sean Olson" To: "Burger, Eric" X-OriginalArrivalTime: 21 Mar 2006 16:40:48.0240 (UTC) FILETIME=[3515C700:01C64D06] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: simple@ietf.org Subject: [Simple] RE: IM delivery reports for conferencing 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: , Errors-To: simple-bounces@ietf.org I agree it should be optional (at the server). If the format of the IMDN does not explicitly allow for this possibility, then no server will be able to implement this functionality. If we don't put this into the format now, then clients won't be able to handle this and we'll need to rev IMDN (needlessly) for conferencing. I'd prefer not to punt the problem=20 -----Original Message----- From: Burger, Eric [mailto:EBurger@cantata.com]=20 Sent: Tuesday, March 21, 2006 8:38 AM To: Sean Olson Cc: simple@ietf.org Subject: RE: IM delivery reports for conferencing I could argue that it is both: the sender might want individual reports; the server, under any circumstance, would rather not batch. Batching would be (should be?) an enhanced, extra cost service, as it imposes a bunch of processing and storage requirements on the server. -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Tuesday, March 21, 2006 9:55 AM To: Burger, Eric; Hisham Khartabil Cc: simple@ietf.org Subject: RE: IM delivery reports for conferencing Caring about notifications is one thing .... Caring whether they are batched together or not is another. The second should be in the control of the server=20 -----Original Message----- From: Burger, Eric [mailto:EBurger@cantata.com] Sent: Monday, March 20, 2006 5:52 PM To: Sean Olson; Hisham Khartabil Cc: simple@ietf.org Subject: RE: IM delivery reports for conferencing I would offer that it MUST be driven by the client - they are the only one that knows whether they care. C.f. the use of notifications for MSRP conferencing. -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Monday, March 20, 2006 4:58 PM To: Hisham Khartabil Cc: Burger, Eric; simple@ietf.org Subject: RE: IM delivery reports for conferencing Well, my opinion obviously is that we do need this capability. However, I don't believe the sender should really be in control of this facet of delivery notifications. In fact if you build in aggregation support now rather than later, than you don't even need to negotiate this. (I propose making receiving aggregated DN support at the sender mandatory)=20 -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] Sent: Monday, March 20, 2006 1:52 PM To: Sean Olson Cc: eburger@brooktrout.com; simple@ietf.org Subject: Re: IM delivery reports for conferencing On Mar 20, 2006, at 10:41 PM, Sean Olson wrote: > The URI attribute only works if you structure the rest of the=20 > information around it.... Are you suggesting aggregation by multipart=20 > MIME or creating a new top-level XML element? I have suggested neither. I doesn't matter really although the latter makes more sense. The question is do we need such feature? and if we do, to allow the sender of the IM to choose which mode or reporting s/he wanted (aggregated or one by one)? If the answer to the first question is yes, then I strongly believe that the answer to the second question is also yes. Hisham > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Wednesday, March 15, 2006 1:49 PM > To: Sean Olson > Cc: eburger@brooktrout.com; simple@ietf.org > Subject: Re: IM delivery reports for conferencing > > > On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: > >> >> Looking at: >> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts >> -00.tx >> t >> And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt >> >> Neither seems to address the use case of an "exploder" or IM=20 >> conferencing where a single IM may have multiple recipients. My=20 >> suggestion is that the schema you choose for the notification allow=20 >> multiple delivery notifications to be batched together with each=20 >> entry > >> distringuished by the recipient URI. > > It does address it to an extent. That's what the "uri" attribute is=20 > there for. If we want to allow aggregation of receipts before sending=20 > the receipt to the IM sender, then we also need to start thinking=20 > about what the sender wants and how to indicate it in the IM itself. > > Hisham > >> >> For example: >> >> For Draft-khartabil-simple-im-receipts-00 >> >> >> 34jk324j >> >> read >> 200 >> The message has been read >> >> >> error >> 415 >> The message could not be=20 >> delivered >> >> >> >> Or, for Draft-burger-simple-imdn-03 >> >> >> >> 1542af3e8b@eburger@example.com >> >> >> >> im:hisham.khartabil@example.net >> >> read >> >> >> >> im:eric.burger@example.net >> >> read >> >> >> >> Sorry if this has been discussed before. Was there a reason this was=20 >> omitted previously? >> >> Thanks, >> Sean >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 21 11:41:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjvQ-0006Dd-Ig; Tue, 21 Mar 2006 11:41:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjvO-0006BD-C9 for simple@ietf.org; Tue, 21 Mar 2006 11:41:38 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjvN-0006td-V2 for simple@ietf.org; Tue, 21 Mar 2006 11:41:38 -0500 X-IronPort-AV: i="4.03,115,1141621200"; d="scan'208"; a="30355400:sNHT196069320" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Mar 2006 11:41:36 -0500 Message-ID: <330A23D8336C0346B5C1A5BB19666647027B0849@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IM delivery reports for conferencing Thread-Index: AcZMaIwp+tCU0MRNToSgG8JDGluh4wAAHCFAAAhAqLAAG1hkEAADi+GAAAAchgAAABNxwA== From: "Burger, Eric" To: "Sean Olson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: simple@ietf.org Subject: [Simple] RE: IM delivery reports for conferencing 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: , Errors-To: simple-bounces@ietf.org Agreed. -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com]=20 Sent: Tuesday, March 21, 2006 11:41 AM To: Burger, Eric Cc: simple@ietf.org Subject: RE: IM delivery reports for conferencing I agree it should be optional (at the server). If the format of the IMDN does not explicitly allow for this possibility, then no server will be able to implement this functionality. If we don't put this into the format now, then clients won't be able to handle this and we'll need to rev IMDN (needlessly) for conferencing. I'd prefer not to punt the problem=20 -----Original Message----- From: Burger, Eric [mailto:EBurger@cantata.com]=20 Sent: Tuesday, March 21, 2006 8:38 AM To: Sean Olson Cc: simple@ietf.org Subject: RE: IM delivery reports for conferencing I could argue that it is both: the sender might want individual reports; the server, under any circumstance, would rather not batch. Batching would be (should be?) an enhanced, extra cost service, as it imposes a bunch of processing and storage requirements on the server. -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Tuesday, March 21, 2006 9:55 AM To: Burger, Eric; Hisham Khartabil Cc: simple@ietf.org Subject: RE: IM delivery reports for conferencing Caring about notifications is one thing .... Caring whether they are batched together or not is another. The second should be in the control of the server=20 -----Original Message----- From: Burger, Eric [mailto:EBurger@cantata.com] Sent: Monday, March 20, 2006 5:52 PM To: Sean Olson; Hisham Khartabil Cc: simple@ietf.org Subject: RE: IM delivery reports for conferencing I would offer that it MUST be driven by the client - they are the only one that knows whether they care. C.f. the use of notifications for MSRP conferencing. -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Monday, March 20, 2006 4:58 PM To: Hisham Khartabil Cc: Burger, Eric; simple@ietf.org Subject: RE: IM delivery reports for conferencing Well, my opinion obviously is that we do need this capability. However, I don't believe the sender should really be in control of this facet of delivery notifications. In fact if you build in aggregation support now rather than later, than you don't even need to negotiate this. (I propose making receiving aggregated DN support at the sender mandatory)=20 -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] Sent: Monday, March 20, 2006 1:52 PM To: Sean Olson Cc: eburger@brooktrout.com; simple@ietf.org Subject: Re: IM delivery reports for conferencing On Mar 20, 2006, at 10:41 PM, Sean Olson wrote: > The URI attribute only works if you structure the rest of the=20 > information around it.... Are you suggesting aggregation by multipart=20 > MIME or creating a new top-level XML element? I have suggested neither. I doesn't matter really although the latter makes more sense. The question is do we need such feature? and if we do, to allow the sender of the IM to choose which mode or reporting s/he wanted (aggregated or one by one)? If the answer to the first question is yes, then I strongly believe that the answer to the second question is also yes. Hisham > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Wednesday, March 15, 2006 1:49 PM > To: Sean Olson > Cc: eburger@brooktrout.com; simple@ietf.org > Subject: Re: IM delivery reports for conferencing > > > On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: > >> >> Looking at: >> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts >> -00.tx >> t >> And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt >> >> Neither seems to address the use case of an "exploder" or IM=20 >> conferencing where a single IM may have multiple recipients. My=20 >> suggestion is that the schema you choose for the notification allow=20 >> multiple delivery notifications to be batched together with each=20 >> entry > >> distringuished by the recipient URI. > > It does address it to an extent. That's what the "uri" attribute is=20 > there for. If we want to allow aggregation of receipts before sending=20 > the receipt to the IM sender, then we also need to start thinking=20 > about what the sender wants and how to indicate it in the IM itself. > > Hisham > >> >> For example: >> >> For Draft-khartabil-simple-im-receipts-00 >> >> >> 34jk324j >> >> read >> 200 >> The message has been read >> >> >> error >> 415 >> The message could not be=20 >> delivered >> >> >> >> Or, for Draft-burger-simple-imdn-03 >> >> >> >> 1542af3e8b@eburger@example.com >> >> >> >> im:hisham.khartabil@example.net >> >> read >> >> >> >> im:eric.burger@example.net >> >> read >> >> >> >> Sorry if this has been discussed before. Was there a reason this was=20 >> omitted previously? >> >> Thanks, >> Sean >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 21 11:59:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkCk-0002EB-63; Tue, 21 Mar 2006 11:59:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkCi-0002E6-HY for simple@ietf.org; Tue, 21 Mar 2006 11:59:32 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLkCh-0007tP-4Z for simple@ietf.org; Tue, 21 Mar 2006 11:59:32 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2LGxPiu001893 for ; Tue, 21 Mar 2006 18:59:30 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 18:58:35 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 18:58:36 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Mar 2006 18:58:33 +0200 Message-ID: In-Reply-To: <330A23D8336C0346B5C1A5BB19666647027B0849@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIMPLE IETF 65 presentations available on the supplementary website Thread-Index: AcZMaIwp+tCU0MRNToSgG8JDGluh4wAAHCFAAAhAqLAAG1hkEAADi+GAAAAchgAAABNxwAAAewuw From: To: X-OriginalArrivalTime: 21 Mar 2006 16:58:36.0184 (UTC) FILETIME=[B1A11980:01C64D08] X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Simple] SIMPLE IETF 65 presentations available on the supplementary website 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: , Errors-To: simple-bounces@ietf.org Hi, The presentations for today's SIMPLE WG session that have been received so far are now available at: http://www.softarmor.com/simple/meets/ietf65/agenda.html Regards, Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 21 13:48:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLlu8-0003WO-GK; Tue, 21 Mar 2006 13:48:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLlu6-0003WJ-K3 for simple@ietf.org; Tue, 21 Mar 2006 13:48:26 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLlu5-0003dW-BT for simple@ietf.org; Tue, 21 Mar 2006 13:48:26 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IWH00KW8QRE47@usaga01-in.huawei.com> for simple@ietf.org; Tue, 21 Mar 2006 10:45:14 -0800 (PST) Received: from jys3105061835 (DHCP-Wireless-131-204.ietf65.org [130.129.131.204]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IWH001P0QRBI2@usaga01-in.huawei.com> for simple@ietf.org; Tue, 21 Mar 2006 10:45:14 -0800 (PST) Date: Tue, 21 Mar 2006 12:48:06 +0800 From: Xiao Wang To: hisham.khartabil@telio.no Message-id: <002601c64ca2$ab503090$cc838182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: simple@ietf.org Subject: [Simple] Doubt about draft-khartabil-simple-im-receipts-00 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="===============0593703361==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0593703361== Content-type: multipart/alternative; boundary="Boundary_(ID_e0iLR1pqr2aC8F6pg+HLZA)" This is a multi-part message in MIME format. --Boundary_(ID_e0iLR1pqr2aC8F6pg+HLZA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, Hisham Just read draft-khartabil-simple-im-receipts-00, and have some doubts. In the draft, "If the message was delivered to multiple recipients, the element in the XML body is used to identify the recipient.", if the meaning is XML body contains multiple elements or contains the recipients' list? Whether can sender receive multiple reports, successful delivery and receiver read and ... Xiao --Boundary_(ID_e0iLR1pqr2aC8F6pg+HLZA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi, Hisham
 
    Just read draft-khartabil-simple-im-receipts-00, and have some doubts.
In the draft, "If the message was delivered to multiple recipients, the <recipient-uri>
element in the XML body is used to identify the recipient.", if the meaning is XML body contains
multiple <recipient-uri> elements or <recipient-uri> contains the recipients' list?
 
Whether can sender receive multiple reports, successful delivery and receiver read and ...
 
 
Xiao
--Boundary_(ID_e0iLR1pqr2aC8F6pg+HLZA)-- --===============0593703361== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0593703361==-- From simple-bounces@ietf.org Tue Mar 21 14:00:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLm5j-0001dx-2q; Tue, 21 Mar 2006 14:00:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLm5h-0001di-I4 for simple@ietf.org; Tue, 21 Mar 2006 14:00:25 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLm5d-00042T-0j for simple@ietf.org; Tue, 21 Mar 2006 14:00:25 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 99AC5194485 for ; Tue, 21 Mar 2006 20:00:19 +0100 (CET) Received: from [130.129.134.123] ([130.129.134.123]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 19:58:35 +0100 In-Reply-To: <002601c64ca2$ab503090$cc838182@china.huawei.com> References: <002601c64ca2$ab503090$cc838182@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <9437ac4e12e719f1d931f085e9b5f9e4@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Date: Tue, 21 Mar 2006 20:00:51 +0100 To: Xiao Wang X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 21 Mar 2006 18:58:37.0203 (UTC) FILETIME=[75C56630:01C64D19] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: simple@ietf.org Subject: [Simple] Re: Doubt about draft-khartabil-simple-im-receipts-00 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: , Errors-To: simple-bounces@ietf.org The draft does not talk about aggregating receipts. So as it is today,=20= each receipt reports on 1 receiver. There is another thread on the=20 simple mailing list discussing this very issue. Thanks, Hisham On Mar 21, 2006, at 5:48 AM, Xiao Wang wrote: > Hi, Hisham > =A0 > =A0=A0=A0 Just read draft-khartabil-simple-im-receipts-00, and have = some=20 > doubts. > In the draft, "If the message was delivered to multiple recipients,=20 > the > element in the XML body is used to identify the recipient.", if the=20 > meaning is XML body contains > multiple elements or contains the=20 > recipients' list? > =A0 > Whether can=A0sender receive multiple reports, successful delivery and=20= > receiver read and ... > =A0 > =A0 > Xiao= _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 21 19:46:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrUl-0000gl-Nk; Tue, 21 Mar 2006 19:46:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrUl-0000gg-3R for simple@ietf.org; Tue, 21 Mar 2006 19:46:39 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLrUh-0004J4-4h for simple@ietf.org; Tue, 21 Mar 2006 19:46:38 -0500 Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IWI004GI7HLI8@mailout1.samsung.com> for simple@ietf.org; Wed, 22 Mar 2006 09:46:33 +0900 (KST) Received: from LocalHost ([165.213.178.95]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IWI00FZ87HKLY@mmp2.samsung.com> for simple@ietf.org; Wed, 22 Mar 2006 09:46:33 +0900 (KST) Date: Wed, 22 Mar 2006 09:45:18 +0900 From: =?ks_c_5601-1987?B?wMzBvsfK?= In-reply-to: <330A23D8336C0346B5C1A5BB19666647027B0849@ATLANTIS.Brooktrout.com> To: simple@ietf.org Message-id: <000a01c64d49$e4ac5b50$5fb2d5a5@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Simple] srtp negotiation on SIP (sdp message) 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: , Errors-To: simple-bounces@ietf.org Hi. all. I want to find some draft or document for srtp key negotiation for sip by using sdp messages. I can't find the status. BEST. JP. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 21 20:03:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrkX-0002iY-BP; Tue, 21 Mar 2006 20:02:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrkV-0002ey-Bc for simple@ietf.org; Tue, 21 Mar 2006 20:02:55 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLrkU-0004mD-1s for simple@ietf.org; Tue, 21 Mar 2006 20:02:55 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 21 Mar 2006 17:02:55 -0800 X-IronPort-AV: i="4.03,116,1141632000"; d="scan'208"; a="263363715:sNHT30157404" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2M12rYg014441; Tue, 21 Mar 2006 17:02:53 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 17:02:53 -0800 Received: from [130.129.128.208] ([10.89.16.64]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 17:02:52 -0800 Message-ID: <4420A23B.6000604@cisco.com> Date: Tue, 21 Mar 2006 20:02:51 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?EUC-KR?B?wMzBvsfK?= Subject: Re: [Simple] srtp negotiation on SIP (sdp message) References: <000a01c64d49$e4ac5b50$5fb2d5a5@LocalHost> In-Reply-To: <000a01c64d49$e4ac5b50$5fb2d5a5@LocalHost> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 22 Mar 2006 01:02:52.0867 (UTC) FILETIME=[58C31130:01C64D4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: simple-bounces@ietf.org On this particular topic, the problem is you have oh-so-many choices. See MIKEY, sdescriptions, MIKEY diffie-helman, ZRTP and RTP over DTLS. This question is also more for the mmusic group and not simple. -Jonathan R. ÀÌÁ¾ÇÊ wrote: > Hi. all. > > I want to find some draft or document for srtp key negotiation for sip > by using sdp messages. > > I can't find the status. > > BEST. JP. > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 21 20:10:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrsA-00080S-NO; Tue, 21 Mar 2006 20:10:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrs9-00080N-9e for simple@ietf.org; Tue, 21 Mar 2006 20:10:49 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLrs7-0004te-Ny for simple@ietf.org; Tue, 21 Mar 2006 20:10:49 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 883C3194487 for ; Wed, 22 Mar 2006 02:10:46 +0100 (CET) Received: from [130.129.134.123] ([130.129.134.123]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 02:09:01 +0100 Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: 'simple@ietf.org' WG From: Hisham Khartabil Date: Wed, 22 Mar 2006 02:11:15 +0100 X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 22 Mar 2006 01:09:05.0442 (UTC) FILETIME=[36D58020:01C64D4D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Simple] The fate of PIDFConn 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: , Errors-To: simple-bounces@ietf.org During the SIMPLE WG meeting, the PIDFConn updated internet draft (http://www.ietf.org/internet-drafts/draft-ala-kurikka-simple-pidfconn -01.txt) was presented. A poll was taken in the WG meeting asking the question of whether the WG would like to take this draft on as a WG item. There was an overwhelming majority that voted for *not* taking on this work in the SIMPLE WG. If there are folks that were not present at the WG meeting that would like to voice their opinion to the contrary of what was agreed, please speak now. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Mar 21 21:16:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLstS-0006uT-QE; Tue, 21 Mar 2006 21:16:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLstR-0006uN-9K for simple@ietf.org; Tue, 21 Mar 2006 21:16:13 -0500 Received: from ousrvr.oulu.fi ([130.231.240.1] helo=oulu.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLstP-0007yJ-Pc for simple@ietf.org; Tue, 21 Mar 2006 21:16:13 -0500 Received: from paju.oulu.fi (paju.oulu.fi [130.231.240.20]) by oulu.fi (8.13.1/8.13.1) with ESMTP id k2M2GAHR026858 for ; Wed, 22 Mar 2006 04:16:10 +0200 (EET) Received: from [127.0.0.1] (paju.oulu.fi [130.231.240.20]) by paju.oulu.fi (8.12.10/8.12.10) with ESMTP id k2M2Fk3d021557 for ; Wed, 22 Mar 2006 04:15:59 +0200 (EET) Message-ID: <4420B350.9020804@ee.oulu.fi> Date: Wed, 22 Mar 2006 04:15:44 +0200 From: Erkki Harjula User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: simple@ietf.org Subject: Re: [Simple] The fate of PIDFConn References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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: , Errors-To: simple-bounces@ietf.org The new "range" attribute, which was considered bad, got basically all the attention in today's session. Anyway, that was only a small addition to the draft. Generally, expressing connectivity features in PIDF has got only positive feedback earlier. So, it would be a pity to disband this work completely and be satisfied with only the current "priority" attribute in PIDF for expressing the features of communication addresses. Mapping more than one features of a communication address (connectivity) to a single "priority" decimal number is impossible. -Erkki Hisham Khartabil wrote: > During the SIMPLE WG meeting, the PIDFConn updated internet draft > (http://www.ietf.org/internet-drafts/draft-ala-kurikka-simple-pidfconn-01.txt) > was presented. A poll was taken in the WG meeting asking the question > of whether the WG would like to take this draft on as a WG item. There > was an overwhelming majority that voted for *not* taking on this work > in the SIMPLE WG. > > If there are folks that were not present at the WG meeting that would > like to voice their opinion to the contrary of what was agreed, please > speak now. > > Regards, > Hisham > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- ___________________________________________________________________ Erkki Harjula, Researcher MediaTeam Oulu Group, University of Oulu Erkki Koiso-Kanttilan katu 3, FIN-90014 University of Oulu, Finland e-mail: erkki.harjula@ee.oulu.fi, http://www.mediateam.oulu.fi tel. +358-8-5532543, mob. +358-50-3030478, fax. +358-8-5532534 ___________________________________________________________________ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 23 18:50:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMZZK-00014q-8B; Thu, 23 Mar 2006 18:50:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMZZ6-0000yY-1p; Thu, 23 Mar 2006 18:50:04 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMZZ3-0004wh-VQ; Thu, 23 Mar 2006 18:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k2NNo1vP010943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Mar 2006 23:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FMZZ3-0001CB-HF; Thu, 23 Mar 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 23 Mar 2006 18:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-09.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: , Errors-To: simple-bounces@ietf.org --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 : The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-09.txt Pages : 68 Date : 2006-3-23 This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-09.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-xcap-09.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-xcap-09.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: <2006-3-23150339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-23150339.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Fri Mar 24 11:40:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMpKl-0008MM-Uy; Fri, 24 Mar 2006 11:40:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMpHN-000636-Lj; Fri, 24 Mar 2006 11:36:49 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMp9t-0007Q5-BF; Fri, 24 Mar 2006 11:29:08 -0500 Received: from [130.129.129.164] (DHCP-Wireless-129-164.ietf65.org [130.129.129.164]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2OGQEQM039971 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 24 Mar 2006 10:26:16 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: References: <0B23EA50-279C-4548-B7F1-4CB334ABF93E@nostrum.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03A46163-DFB6-4B76-8473-BF187AF4ED65@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Fri, 24 Mar 2006 10:26:22 -0600 To: Robert Sparks X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 130.129.129.164 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: "sip@ietf.org WG" , sip-implementors@cs.columbia.edu, Sipping WG , "simple@ietf.org list" Subject: [Simple] SIPit 18 Registration closes in 7 days 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: , Errors-To: simple-bounces@ietf.org Registration for SIPit 18 closes March 31 (7 days from now). If you are planning to attend, but have not already registered, do so now. (if circumstances are forcing you to wait until the last minute, please drop me a note. Late registrations are going to be difficult to accept). Thanks, RjS On Feb 6, 2006, at 11:42 PM, Robert Sparks wrote: > Registration for SIPit 18 is open. > > This event will be held April 17-21 in > Akihabara, Tokyo, Japan. More information > about the event is available at http://www.sipit.net > and the host website at http://www.nic.ad.jp/en/sipit18/ > > Registration will close March 31. Please register early. > You can register now using https://www.regonline.com/88905 > > This 18th SIPForum SIPit is > > Hosted by: > - Japan Network Information Center (JPNIC) > > Co-hosted by: > - WIDE Project > - VoIP System Interoperability Task Force > > Supported by: > - Ministry of Internal Affairs and Communications (MIC) > - The Telecommunication Technology Committee (TTC) > - Telecom Service Association (TELESA) > - VoIP Forum Japan (VFJ) > - IPv6 Promotion Council (v6PC) > - ENUM Trial Japan (ETJP) > > Sponsors: > - Cisco Systems, Inc. > - Fractalist Inc. > - Fusion Communications Corporation > - Japan Telecom Co., Ltd. > - KDDI Corporation > - Mitsubishi Electric Information Network Corporation > - Mitsubishi Research Institute, Inc. > - NEC Corporation > - Netmarks Inc. > - Nippon Telegraph and Telephone Corporation > - Nippon Telegraph and Telephone East Corporation > - Nippon Telegraph and Telephone West Corporation > - NTT Advanced Technology Corporation > - Oki Electric Industry Co., Ltd. > - SoftBank BB Corp. > - Softfront > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 27 14:32:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNxRm-0008Pn-NF; Mon, 27 Mar 2006 14:32:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNxRl-0008Pi-Ka for simple@ietf.org; Mon, 27 Mar 2006 14:32:13 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNxRl-0005mb-9r for simple@ietf.org; Mon, 27 Mar 2006 14:32:13 -0500 Received: from [172.17.2.252] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2RJW8Bh092176 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 27 Mar 2006 13:32:11 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Mon, 27 Mar 2006 13:32:18 -0600 To: "simple@ietf.org list" X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Subject: [Simple] WGLC : draft-ietf-simple-xcap-09.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: , Errors-To: simple-bounces@ietf.org This is a SIMPLE working group Last Call for Comments on draft-ietf- simple-xcap-09. This last call ends in two weeks - April 10, 2006 The previous version of this draft was approved for publication, but was removed from the RFC editor's queue to address a technical issue with conditional inserts. The group also agreed to incorporate several clarifying text changes while the document was open. Please review the changes carefully and send feedback to the SIMPLE list, copying Jonathan. RjS On Mar 23, 2006, at 5:50 PM, Internet-Drafts@ietf.org wrote: > 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 : The Extensible Markup Language (XML) Configuration Access > Protocol (XCAP) > Author(s) : J. Rosenberg > Filename : draft-ietf-simple-xcap-09.txt > Pages : 68 > Date : 2006-3-23 > > This specification defines the Extensible Markup Language (XML) > Configuration Access Protocol (XCAP). XCAP allows a client to read, > write and modify application configuration data, stored in XML format > on a server. XCAP maps XML document sub-trees and element attributes > to HTTP URIs, so that these components can be directly accessed by > HTTP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-09.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-xcap-09.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-xcap-09.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. > Content-Type: text/plain > Content-ID: <2006-3-23150339.I-D@ietf.org> > > _______________________________________________ > 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 Mar 27 14:35:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNxUV-0001zW-53; Mon, 27 Mar 2006 14:35:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNxUT-0001yW-KO for simple@ietf.org; Mon, 27 Mar 2006 14:35:01 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNxUT-0005qh-C2 for simple@ietf.org; Mon, 27 Mar 2006 14:35:01 -0500 Received: from [172.17.2.252] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2RJYw5C092249 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 27 Mar 2006 13:35:00 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <6A6473FC-C145-43FC-BC3C-B7B9DD251748@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "simple@ietf.org list" From: Robert Sparks Date: Mon, 27 Mar 2006 13:35:08 -0600 X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Simple] updated last-call schedule 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: , Errors-To: simple-bounces@ietf.org Based on the feedback during last week's meeting, we're adjusting the last call schedule as follows: 3/27-4/10 : xcap 4/10-5/1 : xml-patch, partial-* (3 weeks - several drafts, overlaps SIPit) 5/1-5/15: presence-rules RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Mar 27 18:05:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO0mW-0005pX-UM; Mon, 27 Mar 2006 18:05:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO0mV-0005pS-JO for simple@ietf.org; Mon, 27 Mar 2006 18:05:51 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO0mU-00011g-Ab for simple@ietf.org; Mon, 27 Mar 2006 18:05:51 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 27 Mar 2006 15:05:50 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,136,1141632000"; d="scan'208"; a="24569510:sNHT23372680" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2RN5nWe004508; Mon, 27 Mar 2006 18:05:49 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Mar 2006 18:05:49 -0500 Received: from [161.44.55.99] ([161.44.55.99]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Mar 2006 18:05:48 -0500 Message-ID: <44286FCC.8000705@cisco.com> Date: Mon, 27 Mar 2006 18:05:48 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Simple] updated last-call schedule References: <6A6473FC-C145-43FC-BC3C-B7B9DD251748@nostrum.com> In-Reply-To: <6A6473FC-C145-43FC-BC3C-B7B9DD251748@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2006 23:05:48.0916 (UTC) FILETIME=[FCA3B340:01C651F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "simple@ietf.org list" 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: , Errors-To: simple-bounces@ietf.org For those that missed it, the xcap document is now in the repository: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-09.txt -Jonathan R. Robert Sparks wrote: > Based on the feedback during last week's meeting, we're adjusting the > last call schedule as follows: > > 3/27-4/10 : xcap > 4/10-5/1 : xml-patch, partial-* (3 weeks - several drafts, overlaps SIPit) > 5/1-5/15: presence-rules > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 29 14:31:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgNu-0008JL-Nb; Wed, 29 Mar 2006 14:31:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgNt-0008JG-Fn for Simple@ietf.org; Wed, 29 Mar 2006 14:31:13 -0500 Received: from uproxy.gmail.com ([66.249.92.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOgNs-00056p-7p for Simple@ietf.org; Wed, 29 Mar 2006 14:31:13 -0500 Received: by uproxy.gmail.com with SMTP id m3so145298ugc for ; Wed, 29 Mar 2006 11:31:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=T9YZFXCJ/7zt23zvMqc006DesQdIWtlNwp/FGFUwLRGhcxNVQUEr2uRyc/0tX2rSSDGndeOHbwjx1jw4qU9wYQ8wXlAKwrjdndNCRQLbnjCIVRKTYDCuF79lyUtM+tK68wNPqKns+V6LyleBEVHijujIa+IgBi9dZKRmC1o/I64= Received: by 10.78.32.14 with SMTP id f14mr29255huf; Wed, 29 Mar 2006 11:31:11 -0800 (PST) Received: by 10.78.75.7 with HTTP; Wed, 29 Mar 2006 11:31:11 -0800 (PST) Message-ID: <6405cd720603291131r5cd4527fq2d2438558d6fe9cc@mail.gmail.com> Date: Wed, 29 Mar 2006 21:31:11 +0200 From: "Harold Harold" To: Simple@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.5 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Simple] MSRP Response vs. Report 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: , Errors-To: simple-bounces@ietf.org Hello, what is the difference between the Response and the Report-Request in MSRP? They both can include a Statuscode. If i have a scenario without relays, that UA1 is sending a SEND-Request to UA2, then why would I need a Report-Request, if the Response can also tell me that the MSRP-Message was received? Thanks, Harold _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Mar 29 14:58:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgog-0004sH-7l; Wed, 29 Mar 2006 14:58:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgof-0004r7-49 for Simple@ietf.org; Wed, 29 Mar 2006 14:58:53 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOgoc-00060T-Oi for Simple@ietf.org; Wed, 29 Mar 2006 14:58:53 -0500 Received: from [172.17.1.114] ([172.17.1.114]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k2TJwmYp027861 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 29 Mar 2006 13:58:48 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: <6405cd720603291131r5cd4527fq2d2438558d6fe9cc@mail.gmail.com> References: <6405cd720603291131r5cd4527fq2d2438558d6fe9cc@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <753DABDA-3D11-480A-855C-DCB728482EEF@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP Response vs. Report Date: Wed, 29 Mar 2006 13:58:45 -0600 To: Harold Harold X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: simple-bounces@ietf.org Responses are hop-by-hop. REPORT is end-to-end. For example, if you have a relay, a SEND request may be successfully delivered to the relay, which generates a successful response. But then the relay fails to deliver to the other end, the relay can send a REPORT indicating the failure. If you do not have relays, and use the default report mode, you won't generally see any REPORT requests. That being said, it is hard to know for sure that you will never talk to someone else who is using a relay, so an implementation should be able to support REPORT. On Mar 29, 2006, at 1:31 PM, Harold Harold wrote: > Hello, > what is the difference between the Response and the Report-Request > in MSRP? > They both can include a Statuscode. > > If i have a scenario without relays, that > UA1 is sending a SEND-Request to UA2, then why would I need a > Report-Request, if the Response can also tell me that the MSRP-Message > was received? > > Thanks, > Harold > > _______________________________________________ > 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 Mar 30 03:45:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOsm5-00031g-HL; Thu, 30 Mar 2006 03:45:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOsm5-00031K-24 for simple@ietf.org; Thu, 30 Mar 2006 03:45:01 -0500 Received: from smtp13.clb.oleane.net ([213.56.31.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOsm1-0008OW-LO for simple@ietf.org; Thu, 30 Mar 2006 03:45:01 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp13.clb.oleane.net with ESMTP id k2U8ifr5027563 for ; Thu, 30 Mar 2006 10:44:56 +0200 Message-Id: <200603300844.k2U8ifr5027563@smtp13.clb.oleane.net> From: "Chantal Ladouce" To: Date: Thu, 30 Mar 2006 10:44:05 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZT1hnURGGW8C3NTP+cNhVo1Zxh/Q== X-Spam-Score: 0.2 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Subject: [Simple] Wireless/WiFi Convergence Conference - 16 to 19 May 2006 - Paris - France 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="===============1465664176==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1465664176== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0274_01C653E6.DDB5CAE0" This is a multi-part message in MIME format. ------=_NextPart_000_0274_01C653E6.DDB5CAE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Wireless/WiFi Convergence Conference - 16 to 19 May 2006 - Paris - France Last days to benefit from the Early Bird Offer! Register before Monday the 3rd of April and save 10 % on the Registration Fees. For more info and to register, please visit: http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006terms.htm ------=_NextPart_000_0274_01C653E6.DDB5CAE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Wireless/Wi= Fi Convergence Conference - 16 to 19 May 2006 - Paris - France

 =

Last days = to benefit from the Early Bird Offer!

 =

Register before Monday the 3rd of April and save = 10 % on the Registration Fees.

For more info and to register, please = visit:

http://www.upperside.fr/wirelessconvergence2006/wwconvergence= 2006terms.htm

 

------=_NextPart_000_0274_01C653E6.DDB5CAE0-- --===============1465664176== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1465664176==-- From simple-bounces@ietf.org Thu Mar 30 07:11:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOvzd-0004dl-IQ; Thu, 30 Mar 2006 07:11:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOvzc-0004dg-G7 for simple@ietf.org; Thu, 30 Mar 2006 07:11:12 -0500 Received: from wproxy.gmail.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOvzb-0008Mh-A4 for simple@ietf.org; Thu, 30 Mar 2006 07:11:12 -0500 Received: by wproxy.gmail.com with SMTP id 69so785231wra for ; Thu, 30 Mar 2006 04:11:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=VtfnR+dAx8OnTEw7SJvpgBeoxacEQPw+w7MuhN6czHUolkiqA7qVJR2bbFQu+8NSUZWAONrF4C9FbUQfYMD6H5rIYUzuEfE4WKuBq7aKbBEcxYrdX0Txdzysaqs0sSkb0lyavUsnS6LQTjvI3w2O++N2jTIr+CLvNoSVzmhO7Pw= Received: by 10.54.116.18 with SMTP id o18mr660983wrc; Thu, 30 Mar 2006 04:11:10 -0800 (PST) Received: by 10.54.93.7 with HTTP; Thu, 30 Mar 2006 04:11:10 -0800 (PST) Message-ID: <95d59cef0603300411s3755eb02x6999c5c5460b6567@mail.gmail.com> Date: Thu, 30 Mar 2006 15:11:10 +0300 From: "Jussi K. Virtanen" To: "Miguel Garcia" , "Aki Niemi" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 1.9 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: IETF SIMPLE Subject: [Simple] How are participant URIs conveyed from the focus to an MSRP switch? 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: , Errors-To: simple-bounces@ietf.org Hi, In order to be able to forward private messages, an MSRP switch has to maintain an association between an MSRP session and a participant URI. Consider a situation in which the focus of a conference and an MSRP switch that acts as a mixer in the conference are separate and the MSRP switch is not a SIP UA. How are the participant URIs conveyed from the focus to the MSRP switch? Best Regards, -- Jussi K. Virtanen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Mar 30 23:13:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPB0r-00022B-62; Thu, 30 Mar 2006 23:13:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPB0p-00021u-3w; Thu, 30 Mar 2006 23:13:27 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPB0m-0002DA-OE; Thu, 30 Mar 2006 23:13:27 -0500 Received: from [192.168.0.105] ([71.240.162.175]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k2V4D5W4008945 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 30 Mar 2006 22:13:06 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <03A46163-DFB6-4B76-8473-BF187AF4ED65@nostrum.com> References: <0B23EA50-279C-4548-B7F1-4CB334ABF93E@nostrum.com> <03A46163-DFB6-4B76-8473-BF187AF4ED65@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Thu, 30 Mar 2006 22:12:55 -0600 To: "sip@ietf.org WG" , Sipping WG , "simple@ietf.org list" , Sip-Implementors X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 71.240.162.175 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Subject: [Simple] SIPit 18 registration closes today (Friday 3/31) 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: , Errors-To: simple-bounces@ietf.org Registration for SIPit 18 closes today (Friday 3/31). If you plan to attend but have not yet registered, please do so right away. Thanks, RjS On Feb 6, 2006, at 11:42 PM, Robert Sparks wrote: > Registration for SIPit 18 is open. > > This event will be held April 17-21 in > Akihabara, Tokyo, Japan. More information > about the event is available at http://www.sipit.net > and the host website at http://www.nic.ad.jp/en/sipit18/ > > Registration will close March 31. Please register early. > You can register now using https://www.regonline.com/88905 > > This 18th SIPForum SIPit is > > Hosted by: > - Japan Network Information Center (JPNIC) > > Co-hosted by: > - WIDE Project > - VoIP System Interoperability Task Force > > Supported by: > - Ministry of Internal Affairs and Communications (MIC) > - The Telecommunication Technology Committee (TTC) > - Telecom Service Association (TELESA) > - VoIP Forum Japan (VFJ) > - IPv6 Promotion Council (v6PC) > - ENUM Trial Japan (ETJP) > > Sponsors: > - Cisco Systems, Inc. > - Fractalist Inc. > - Fusion Communications Corporation > - Japan Telecom Co., Ltd. > - KDDI Corporation > - Mitsubishi Electric Information Network Corporation > - Mitsubishi Research Institute, Inc. > - NEC Corporation > - Netmarks Inc. > - Nippon Telegraph and Telephone Corporation > - Nippon Telegraph and Telephone East Corporation > - Nippon Telegraph and Telephone West Corporation > - NTT Advanced Technology Corporation > - Oki Electric Industry Co., Ltd. > - SoftBank BB Corp. > - Softfront > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Mar 31 08:22:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPJZy-0003Ty-Qq; Fri, 31 Mar 2006 08:22:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPJZx-0003TW-Hm for Simple@ietf.org; Fri, 31 Mar 2006 08:22:17 -0500 Received: from uproxy.gmail.com ([66.249.92.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPJZx-0001Yb-3D for Simple@ietf.org; Fri, 31 Mar 2006 08:22:17 -0500 Received: by uproxy.gmail.com with SMTP id u2so332987uge for ; Fri, 31 Mar 2006 05:22:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=p3lZI7grQri9Syo0snAtCcMBvJ5YPOd6i80gkTR+5tI1E3QAStizmDKHRElxjqFM1QCatDvETjB+fD+/RN/5NjorHi7K+imNYSHZBWPhFs+a2LCxw/WcU5pusRxGb51FvtGCGQWsCemnJJX0edSDINLJuNXrrdo9wymW7ChNTYk= Received: by 10.78.58.11 with SMTP id g11mr30596hua; Fri, 31 Mar 2006 05:22:16 -0800 (PST) Received: by 10.78.75.7 with HTTP; Fri, 31 Mar 2006 05:22:15 -0800 (PST) Message-ID: <6405cd720603310522x1b0117e1jc32052a38ac4a77d@mail.gmail.com> Date: Fri, 31 Mar 2006 15:22:15 +0200 From: jos4711@googlemail.com To: "Ben Campbell" Subject: Re: [Simple] MSRP Response vs. Report In-Reply-To: <753DABDA-3D11-480A-855C-DCB728482EEF@estacado.net> MIME-Version: 1.0 References: <6405cd720603291131r5cd4527fq2d2438558d6fe9cc@mail.gmail.com> <753DABDA-3D11-480A-855C-DCB728482EEF@estacado.net> X-Spam-Score: 1.2 (+) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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: , Content-Type: multipart/mixed; boundary="===============0608526422==" Errors-To: simple-bounces@ietf.org --===============0608526422== Content-Type: multipart/alternative; boundary="----=_Part_17703_25722175.1143811335966" ------=_Part_17703_25722175.1143811335966 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Okay, so if there are relays, then the REPORTS are the only possibility to let the endpoint know if his SEND was successful or not. That is because Responses are hop-by-hop and REPORTS are end-to-end. So if i have: A<--------->Relay<-------->B and A sends a SEND Sceanrio 1: To let A know that his SEND was received, B sends a REPORT directly to A, right after he has send a Response to the Relay Scenario 2: The Response from B to the Relay got lost, the Relay sends a REPORT directly to A Possible Scenario 3: Is it possible that B sends a REPORT that goes not directly to A, instead it goes first to the Relay and from the Relay to A, then its not end-to-end anymore, right? 1. 2006/3/29, Ben Campbell : > > Responses are hop-by-hop. REPORT is end-to-end. For example, if you > have a relay, a SEND request may be successfully delivered to the > relay, which generates a successful response. But then the relay > fails to deliver to the other end, the relay can send a REPORT > indicating the failure. > > If you do not have relays, and use the default report mode, you won't > generally see any REPORT requests. That being said, it is hard to > know for sure that you will never talk to someone else who is using a > relay, so an implementation should be able to support REPORT. > > On Mar 29, 2006, at 1:31 PM, Harold Harold wrote: > > > Hello, > > what is the difference between the Response and the Report-Request > > in MSRP? > > They both can include a Statuscode. > > > > If i have a scenario without relays, that > > UA1 is sending a SEND-Request to UA2, then why would I need a > > Report-Request, if the Response can also tell me that the MSRP-Message > > was received? > > > > Thanks, > > Harold > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > ------=_Part_17703_25722175.1143811335966 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Okay, so if there are relays, then the REPORTS are the only possibilit= y to let the endpoint know if his SEND was successful or not.
That is because Responses are hop-by-hop and REPORTS are end-to-end.
 
So if i have:
A<--------->Relay<-------->B
and A sends a SEND
 
Sceanrio 1: To let A know that his SEND was received, B sends a REPORT= directly to A, right after he has send a Response to the Relay
Scenario 2: The Response from B to the Relay got lost, the Relay sends= a REPORT directly to A
Possible Scenario 3: Is it possible that B sends a REPORT that goes no= t directly to A, instead it goes first to the Relay and from the Relay to A= , then its not end-to-end anymore, right?
 
1.
2006/3/29, Ben Campbell <ben@estacado.net>:
Responses are hop-by-hop. REPORT= is end-to-end. For example, if you
have a relay, a SEND request may be = successfully delivered to the
relay, which generates a successful response. But then the relay
fai= ls to deliver to the other end, the relay can send a REPORT
indicating t= he failure.

If you do not have relays, and use the default report mo= de, you won't
generally see any REPORT requests. That being said, it is hard to
kn= ow for sure that you will never talk to someone else who is using a
rela= y, so an implementation should be able to support REPORT.

On Mar 29,= 2006, at 1:31 PM, Harold Harold wrote:

> Hello,
> what is the difference between the Response and= the Report-Request
> in MSRP?
> They both can include a Status= code.
>
> If i have a scenario without relays, that
> UA1= is sending a SEND-Request to UA2, then why would I need a
> Report-Request, if the Response can also tell me that the MSRP-Mes= sage
> was received?
>
> Thanks,
> Harold
>> _______________________________________________
> Simple maili= ng list
> Simple@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/simple


------=_Part_17703_25722175.1143811335966-- --===============0608526422== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0608526422==-- From simple-bounces@ietf.org Fri Mar 31 15:25:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPQBb-0002KR-5I; Fri, 31 Mar 2006 15:25:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPQ4t-00008I-9s for simple@ietf.org; Fri, 31 Mar 2006 15:18:39 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPQ4r-0003Hb-Vx for simple@ietf.org; Fri, 31 Mar 2006 15:18:39 -0500 Received: from [172.17.2.252] ([172.17.2.252]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k2VKIadF070913 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 31 Mar 2006 14:18:37 -0600 (CST) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Fri, 31 Mar 2006 14:18:34 -0600 To: "simple@ietf.org list" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-Mailman-Approved-At: Fri, 31 Mar 2006 15:25:31 -0500 Cc: Subject: [Simple] Draft minutes SIMPLE IETF65 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: , Errors-To: simple-bounces@ietf.org Please review the draft minutes for our recent Dallas SIMPLE meeting at http://www.nostrum.com/~rjsparks/simple-65-minutes.html Send comments/corrections to this list or directly to the chairs no later than Friday April 7. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple