From simple-bounces@ietf.org Wed Feb 01 17:28:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4QSi-0003yJ-Ly; Wed, 01 Feb 2006 17:28:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13sy-0008JS-P1 for simple@megatron.ietf.org; Mon, 23 Jan 2006 10:45:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28695 for ; Mon, 23 Jan 2006 10:44:11 -0500 (EST) Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F142L-0002cq-Hj for simple@ietf.org; Mon, 23 Jan 2006 10:55:22 -0500 Received: from [172.17.2.130] (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k0NFjW21075530 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 23 Jan 2006 09:45:33 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <2FA3CB4B-F368-4F1E-AB66-961C9D520C42@nostrum.com> From: Ben Campbell Subject: Re: [Simple] MSRP Report Model Date: Mon, 23 Jan 2006 09:45:12 -0600 To: Amitkumar.Goel@infineon.com X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (shaman.nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab X-Mailman-Approved-At: Wed, 01 Feb 2006 17:28:04 -0500 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="===============1707990888==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1707990888== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-810140268; protocol="application/pkcs7-signature" --Apple-Mail-1-810140268 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit 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. > > 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. > 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. --Apple-Mail-1-810140268 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGEjCCAssw ggI0oAMCAQICAw/3ODANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUxMjAxMjAxNjE4WhcNMDYxMjAxMjAxNjE4WjBBMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR4wHAYJKoZIhvcNAQkBFg9iZW5Abm9zdHJ1bS5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBixDn5vhg7wN4UQ2+YIrg8fqJwFIrvLLq 8DG1MPMBgED41t/8AV2Nr1SxFBpeOWVheybhX5wuhyxOnckD9+/BK7XvMKgoemmqLOEPuWcHEYcd 6LnfyONdgwWFktkDCBOItsTsFKwnvDOxxqimB+XujesLiiW4RehTr+VardvlK+G1C7HuOKBdtoMQ 7oKe4vcvmEEAEU5SW2QakSMqhU71jPF1CKDXU1GiED/AKhKyfnzro3foAYz3F9Ft955b7yxhh1C7 wZQb3w1TR9zOdGOXiW412o0aV7urhDBAtLe2xrQgkR72QJiHqPMSJiVdQIigF36jMZQ9NHJKpf7D esmNAgMBAAGjLDAqMBoGA1UdEQQTMBGBD2JlbkBub3N0cnVtLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBAUAA4GBAIiKtCOlxRCFseWmINkArjOvgOVbIzyemTP6obDbWTHHxDAZy6hq8WGi WqUsqa068A1knCR6p9Tof3WmFdxIpxtR919CgPfpRuQcApMro9eG12HfwCMhkMz3etP8XSBjrlkp A2vrvRYNlkDU2+fZVUtbQRdaH+SG9P6egqx8Hp8iMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0B AQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv biBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAw MDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoT zyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GU MIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3 dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQ g+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsA xRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXe JLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMP9zgwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMDYwMTIzMTU0NTEzWjAjBgkqhkiG9w0BCQQxFgQUHnFEAfHmIv9n/LvU OVU2qWn8rkwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0ECAw/3ODB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMP9zgwDQYJKoZIhvcNAQEBBQAEggEAiSQSj7/ta4eLDQ3h 8Ryo/MKVLCMc9xK4lu8JWhAccXbotrhE/ABZe3/YuG8uEzYD0qMz/DIzpQpBVZHmooQv40tSXq+k bbdgtRTuZO4C2VqHX9Hj7smIcjIEn+Hf0TUrv1zGjLCMVMsLYSOjuRCD9NE209sQ67uWNW1fFEhR T5VbiULaG3FK2KDSpnLGc79DAxteHooVa/ELicCbYs7heVW40pAE9cJ5tbK2m00HJZf+Nfgvguf5 dxzT/Bjc7HKiTr0wt4dOfoKUK3lMNQE7IgjQ6wRTisvaPv3GZ/rXjyaq+BgyszVCh8iLyLyztYLE H2e1sApG9k1w75IUmpiMyAAAAAAAAA== --Apple-Mail-1-810140268-- --===============1707990888== 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 --===============1707990888==-- From simple-bounces@ietf.org Thu Feb 02 05:52:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4c4X-00046C-Ej; Thu, 02 Feb 2006 05:52:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4c4N-00043z-KB for simple@megatron.ietf.org; Thu, 02 Feb 2006 05:52:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20552 for ; Thu, 2 Feb 2006 05:50:17 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4cFW-0005vi-PA for simple@ietf.org; Thu, 02 Feb 2006 06:03:40 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by mx2.foretec.com with esmtp (Exim 4.24) id 1F4c49-0001H3-2G for simple@ietf.org; Thu, 02 Feb 2006 05:51:53 -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 k12AmdaE029875; Thu, 2 Feb 2006 12:48:44 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 12:51:42 +0200 Received: from [172.21.35.128] ([172.21.35.128]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 2 Feb 2006 12:51:41 +0200 Message-ID: <43E1E43D.7080803@nokia.com> Date: Thu, 02 Feb 2006 12:51:41 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "ext Burger, Eric" Subject: Re: [Simple] IMDN issue #10: More than one IMDN for an IM References: <330A23D8336C0346B5C1A5BB196666470219B7A7@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB196666470219B7A7@ATLANTIS.Brooktrout.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2006 10:51:41.0517 (UTC) FILETIME=[A6733FD0:01C627E6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext Burger, Eric wrote: > I'll buy the argument, if we said that every IM generates an IMDN. > Given the scenarios Hisham and Aki have posted, the sender has no way of > knowing whether or not there are intermediaries. This is why every IM > must request an IMDN, unless the sender does not care. RFC3428 states that receipt of a 202 (as opposed to 200) tells the sender that there is (possibly) an intermediary in the picture. It's a different question as to how useful that indication is, but at least there is one. > This issue also says that SIP was the wrong choice for IM transport. > We're hacking hacks on hacks to implement transport layer features. I'm not sure I understand where you draw that conclusion. But as long as we're making conclusions about transports, I think UDP was the wrong choice for SIP IM. ;) > Yes, it will work to use IMDN for what in the normal SIP world would be > a final response. Does this pass muster with the Internet architecture, > however? SIP MESSAGE is hop-by-hop in this case, same as with email. IM does allow this concept of an IM inbox that is in the network, so there is always a possibility that a message is not delivered to the agent that ends up consuming it immediately after being received by this IM inbox. Cheers, Aki > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Tuesday, January 31, 2006 4:12 AM > To: Burger, Eric > Cc: Simple WG > Subject: Re: [Simple] IMDN issue #10: More than one IMDN for an IM > > I dont understand your point here. what ACK for the message? do you > mean 200 ok? > > While 200 ok is transport level delivery, IMDN is user level delivery > notification. A GW, for example, can generate a 2xx response before it > has been guaranteed that the final recipient has actually received the > message. > > Hisham > > On Jan 30, 2006, at 9:35 PM, Burger, Eric wrote: > >> REPORT method tells you the IM was received. >> ACK of the MESSAGE tells you the IM was received. >> >> IMDN is for user-level read, not transport. This is the distinction >> between user-level (IMDN, MDN) and transport-level (MESSAGE, ACK, SMTP >> DSN) reporting. >> >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >> Behalf >> Of Hisham Khartabil >> Sent: Friday, January 27, 2006 10:19 AM >> To: Simple WG >> Subject: [Simple] IMDN issue #10: More than one IMDN for an IM >> >> The draft states: >> >> "The Reporting UAS MUST NOT send more than one final IMDN in response >> to an IMDN request. That is, once an IMDN has been issued on >> behalf >> of a recipient, no further IMDNs may be issued on behalf of that >> recipient, even if another disposition is performed on the > message. >> For example, if the user reads and then deletes the message, the >> UAS >> will send a single read notification. The delete operation in > this >> case will not generate an additional IMDN." >> >> I do not agree. I would like to know when the message is delivered, >> then when the message is read and when whatever future state we come > up >> with for an IM happens. >> >> Regards, >> Hisham >> >> >> >> _______________________________________________ >> 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 Feb 02 12:04:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4htD-0001PT-FG; Thu, 02 Feb 2006 12:04:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4htB-0001Ob-9m for simple@megatron.ietf.org; Thu, 02 Feb 2006 12:04:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20717 for ; Thu, 2 Feb 2006 12:03:09 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4i4P-0003FK-5V for simple@ietf.org; Thu, 02 Feb 2006 12:16:35 -0500 X-IronPort-AV: i="4.01,248,1136178000"; d="scan'208"; a="27407905:sNHT49393512" 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 Subject: RE: [Simple] IMDN issue #8: List-Action, Original-From and Original-Message-ID Date: Thu, 2 Feb 2006 12:05:17 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664701A58CC7@ATLANTIS.Brooktrout.com> Thread-Topic: [Simple] IMDN issue #8: List-Action, Original-From and Original-Message-ID Thread-Index: AcYjVewn9W8Pab4DQTeVb3uEpyKgcAEHBuxQ From: "Burger, Eric" To: "Hisham Khartabil" X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Yes, Original-* and List-Action could support the direct reporting from the UAS to the UAC. However, they are necessary to solve a thorny problem that B2BUA's introduce. Namely, by the strict definition of delivery, the B2BUA MUST issue the IMDN, and that is the end of the story. The B2BUA has no right to request a downstream IMDN, nor does it have the right to relay the downstream IMDN back to the Requesting UAC. I agree the most common user interpretation of IMDN is that it is for the final UAS, even through a gateway or exploder, to do the reporting. HOWEVER, it is no the only case. Given that the plan below breaks the definition of a UAS (the UAS half of a UAC) and it does not allow users or intelligent agents who really only care if the message was processed at the gateway or list exploder, I would offer that we use a mechanism that works for all scenarios. I would also offer the mechanism proposed in the text works for all scenarios. [Note to Hisham - are you referring to the mechanism in draft-burger-simple-imdn-01 or draft-ietf-simple imdn-00? I don't think anyone has seen draft-ietf-simple-imdn-00 yet. The ietf-simple-imdn mechanism is very different (although backwards compatible) with the burger-simple-imdn mechanism.] -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Hisham Khartabil Sent: Friday, January 27, 2006 10:19 AM To: Simple WG Subject: [Simple] IMDN issue #8: List-Action,Original-From and Original-Message-ID I don't think the List-Action header is needed. The Original-From=20 header and Original-Message-ID may not be needed also. this depends on=20 how we define the behaviour of the IM exploder to be. To summarise: - List-Action header is used to indicate if a B2BUA or UAS is to do=20 the reporting - Original-From allows a UAS to know there to send the notification if=20 there was a B2BUA like an exploder on the path. - Original-Message-ID allows a UAS to indicate to the UAC the=20 message-ID of the original message that the notification is for. This=20 is also when a B2BUA is involved. All 3 headers are above to help the case that a UAC chooses for the UAS=20 to send the notifications directly instead of the B2BUA generating them=20 indicating the B2BUA's receipt of the message. I would design it as follows: - UAC indicates, in the IM, its wish to receive an IMDN - B2BUA forwards the IM with the necessary original-from and=20 original-message-id headers (if needed) - the UAS generates the IMDN and sends it just like it would send an IM=20 to the UAC. For MSRP, it would be just like a SEND request in the other=20 direction. For SIP MESSAGE, it would use the from (or original-from)=20 and to headers in the incoming IM to create the MESSAGE request in the=20 reverse direction. Same applies for message-id. - If it was not possible for the B2BUA to reach the UAS, it would=20 generate its own IMDNs for that IM. Regards, Hisham _______________________________________________ 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 Feb 02 13:43:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4jR1-0001Ee-OK; Thu, 02 Feb 2006 13:43:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4jR0-0001C4-2F for simple@megatron.ietf.org; Thu, 02 Feb 2006 13:43:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28056 for ; Thu, 2 Feb 2006 13:42:14 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4jcH-0006Zm-Pq for simple@ietf.org; Thu, 02 Feb 2006 13:55:40 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 2CA4F194497 for ; Thu, 2 Feb 2006 19:43:29 +0100 (CET) Received: from [192.168.1.98] ([192.168.1.98]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 19:42:13 +0100 In-Reply-To: <330A23D8336C0346B5C1A5BB1966664701A58CC7@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB1966664701A58CC7@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <39cbabda8358825387a27ec15ff95d77@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] IMDN issue #8: List-Action, Original-From and Original-Message-ID Date: Thu, 2 Feb 2006 19:43:38 +0100 To: "Burger, Eric" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 02 Feb 2006 18:42:13.0361 (UTC) FILETIME=[61F0C610:01C62828] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Feb 2, 2006, at 6:05 PM, Burger, Eric wrote: > Yes, Original-* and List-Action could support the direct reporting from > the UAS to the UAC. However, they are necessary to solve a thorny > problem that B2BUA's introduce. Namely, by the strict definition of > delivery, the B2BUA MUST issue the IMDN, and that is the end of the > story. The B2BUA has no right to request a downstream IMDN, nor does > it > have the right to relay the downstream IMDN back to the Requesting UAC. I disagree. That might be your definition of a B2BUA, not mine. How could a B2BUA issue an IMDN to a IM it has no idea if it has been delivered to a user or not. Especially if the IMDN is a read report. > > I agree the most common user interpretation of IMDN is that it is for > the final UAS, even through a gateway or exploder, to do the reporting. > HOWEVER, it is no the only case. Given that the plan below breaks the > definition of a UAS (the UAS half of a UAC) and it does not allow users > or intelligent agents who really only care if the message was processed > at the gateway or list exploder, I would offer that we use a mechanism > that works for all scenarios. Can you give real world examples of such scenarios where the sender only cares that the GW or B2BUA has the message delivered to it. > > I would also offer the mechanism proposed in the text works for all > scenarios. Can you describe that mechanism to folks who don't have the privilage of seeing the pending WG item version? > > [Note to Hisham - are you referring to the mechanism in > draft-burger-simple-imdn-01 or draft-ietf-simple imdn-00? I don't > think > anyone has seen draft-ietf-simple-imdn-00 yet. The ietf-simple-imdn > mechanism is very different (although backwards compatible) with the > burger-simple-imdn mechanism.] I'm referring to burger-simple-imdn-01. We cannot just change mechanisms without discussion on the mailing list, especially when the draft is a WG item. Thanks, Hisham > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > Behalf > Of Hisham Khartabil > Sent: Friday, January 27, 2006 10:19 AM > To: Simple WG > Subject: [Simple] IMDN issue #8: List-Action,Original-From and > Original-Message-ID > > I don't think the List-Action header is needed. The Original-From > header and Original-Message-ID may not be needed also. this depends on > how we define the behaviour of the IM exploder to be. > > To summarise: > > - List-Action header is used to indicate if a B2BUA or UAS is to do > the reporting > - Original-From allows a UAS to know there to send the notification if > there was a B2BUA like an exploder on the path. > - Original-Message-ID allows a UAS to indicate to the UAC the > message-ID of the original message that the notification is for. This > is also when a B2BUA is involved. > > All 3 headers are above to help the case that a UAC chooses for the UAS > to send the notifications directly instead of the B2BUA generating them > indicating the B2BUA's receipt of the message. > > I would design it as follows: > > - UAC indicates, in the IM, its wish to receive an IMDN > - B2BUA forwards the IM with the necessary original-from and > original-message-id headers (if needed) > - the UAS generates the IMDN and sends it just like it would send an IM > to the UAC. For MSRP, it would be just like a SEND request in the other > direction. For SIP MESSAGE, it would use the from (or original-from) > and to headers in the incoming IM to create the MESSAGE request in the > reverse direction. Same applies for message-id. > - If it was not possible for the B2BUA to reach the UAS, it would > generate its own IMDNs for that IM. > > Regards, > Hisham > > > _______________________________________________ > 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 Feb 02 23:59:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4t33-0004Au-D5; Thu, 02 Feb 2006 23:59:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4t2z-00049J-0s for simple@megatron.ietf.org; Thu, 02 Feb 2006 23:59:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22177 for ; Thu, 2 Feb 2006 23:58:06 -0500 (EST) From: Amitkumar.Goel@infineon.com Received: from smtp3.infineon.com ([203.126.106.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4tEO-0005wi-As for simple@ietf.org; Fri, 03 Feb 2006 00:11:38 -0500 Received: from unknown (HELO sinse211.ap.infineon.com) ([172.17.65.149]) by smtp3.infineon.com with ESMTP; 03 Feb 2006 12:59:25 +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); Fri, 3 Feb 2006 12:59:25 +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 Subject: RE: [Simple] MSRP Report Model Date: Fri, 3 Feb 2006 10:29:22 +0530 Message-ID: Thread-Topic: [Simple] MSRP Report Model Thread-Index: AcYngFuib/fIe2JSQz2RIKFOvUL7GAA/bs7g To: X-OriginalArrivalTime: 03 Feb 2006 04:59:25.0410 (UTC) FILETIME=[9AC30420:01C6287E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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=20 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 =20 > way /some ways of indicating the same (may be this was already=20 > discussed earlier, but I am not aware of). There can be many reasons =20 > for the receiver not to generate REPORT for incoming SEND request. The issue is, if the sender requests success-reports, the sender is=20 requesting reliable delivery of the message. This makes the REPORT=20 effectively part of a end-to-end transaction. If the sender does not=20 receive one in a reasonable period of time, it is likely to attempt=20 to attempt to restart the session, resend the content, etc. Furthermore, a positive delivery report does not indicate that the=20 receiving human has actually seen the message. Only that the endpoint=20 has received it. In this sense, you can think of a positive report to=20 be akin to a SIP 200 OK response, which is certainly not optional. =09 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. > > 1. Congestion on the receiver side I don't think we need an exception for congestion--the endpoint may=20 fail to live up to any aspect of the protocol when congested. We=20 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=20 with presence, which will create quite a bit of traffic. Any=20 additional cost for REPORT requests will probably fall into the noise. =20 > 3. Due to some security or privacy reason > Again, REPORT does not indicate the user has seen the message. It can=20 be sent before rendering of the content. Furthermore, an MSRP session=20 will only exist if negotiated with SIP or some other rendez-vous=20 protocol. Once an endpoint has explicitly indicated its willingness=20 to participate in an MSRP session, actually sending REPORT requests=20 does not seem to leak any information that has not already been=20 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=20 include a negotiation mechanism. =09 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. > 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=20 we cannot depend on this for negotiation. Hope this helps! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 03 11:03:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F53P5-0001kY-W5; Fri, 03 Feb 2006 11:03:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F53P4-0001jp-PN for simple@megatron.ietf.org; Fri, 03 Feb 2006 11:03:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13979 for ; Fri, 3 Feb 2006 11:01:27 -0500 (EST) Received: from mail1.ktf.com ([210.123.92.147]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F53aN-00008L-CN for simple@ietf.org; Fri, 03 Feb 2006 11:15:06 -0500 Received: (snipe 22251 invoked by alias); 4 Feb 2006 00:24:22 +0900 Received: from andrea@ktf.com with Spamsniper 2.83.29 (Processed in 0.016025 secs); Received: from unknown (HELO ktf.com) (203.229.169.101) by unknown with SMTP; 4 Feb 2006 00:24:22 +0900 X-RCPTTO: simple@ietf.org Received: from localhost (root@localhost) by ktf.com (8.9.3 (PHNE_29774)/8.9.3) with ESMTP id BAA21217 for ; Sat, 4 Feb 2006 01:02:37 +0900 (KST) X-OpenMail-Hops: 1 Date: Sat, 4 Feb 2006 01:02:37 +0900 Message-Id: MIME-Version: 1.0 From: "=?EUC-KR?B?wMzA5b/4?=" TO: "=?EUC-KR?B??=" X-Spam-Score: 1.2 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Simple] MSRP with Deferred-delivery Messaging X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============0471109519==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============0471109519== Content-Type: text/html; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Sat, 4 Feb 2006 01:02:37 +0900" 

Hi, everyone.

My question is :
  - MSRP is session-based.
  - SMS/MMS is somewhat kind of page-mode messaging.
  - Can MSRP support SMS/MMS nicely?

MSRP may be unsuitable for serving SMS/MMS, in particular, mobile environment.

Most mobile handset cannot support multi-socket.

Assuming that MSRP serves deferred-delivery messaging such as SMS/MMS,
resources(e.g. TCP connection) must quickly be released as soon as the completion of sending a message.

But MSRP connection is released only if user actively performs BYE.

Is there any method to quickly disconnect MSRP session without waiting for user's intervention 
in the case of deferred-delivery(SMS/MMS)?

Or, is MESSAGE-based mechanism more desirable for this case?

---------------------------------------------------
Jang-Won Lee / Senior
Data N/W Development Team, Network Group, KTF
M) +82-10-3010-1866
L) +82-31-909-0670
Fax) +82-31-909-0661
---------------------------------------------------
--===============0471109519== 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 --===============0471109519==-- From simple-bounces@ietf.org Sat Feb 04 10:32:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5POm-0007uv-RA; Sat, 04 Feb 2006 10:32:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5POk-0007l7-VE for simple@megatron.ietf.org; Sat, 04 Feb 2006 10:32:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14477 for ; Sat, 4 Feb 2006 10:30:32 -0500 (EST) Received: from fep32-0.kolumbus.fi ([193.229.0.63] helo=fep32-app.kolumbus.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5PaF-0007SM-WB for simple@ietf.org; Sat, 04 Feb 2006 10:44:23 -0500 Received: from [84.231.43.47] by fep32-app.kolumbus.fi with ESMTP id <20060204153158.YBEN3516.fep32-app.kolumbus.fi@[84.231.43.47]> for ; Sat, 4 Feb 2006 17:31:58 +0200 Message-ID: <43E4C929.7020907@gmail.com> Date: Sat, 04 Feb 2006 17:32:57 +0200 From: "Jussi K. Virtanen" User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: SIMPLE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Simple] 501 Not Implemented considered harmful in MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, MSRP defines the status code 501 Not Implemented to be sent as a response to a request with unknown request method. I propose that the status code is removed and the status code 400 Bad Request is used instead. The existence of 501 Not Implemented implies that it is acceptable to introduce new capabilities (in this case, a new request method) to a session outside an offer--answer exchange. As far as I can see, this is in conflict with established conventions in SIP and SDP. Best Regards, -- Jussi K. Virtanen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Feb 04 12:22:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5R7O-0000ha-A8; Sat, 04 Feb 2006 12:22:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5R7L-0000g3-Pe for simple@megatron.ietf.org; Sat, 04 Feb 2006 12:22:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22168 for ; Sat, 4 Feb 2006 12:20:56 -0500 (EST) Received: from fep02-0.kolumbus.fi ([193.229.0.44] helo=fep02-app.kolumbus.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5RJ9-0004Gq-Q9 for simple@ietf.org; Sat, 04 Feb 2006 12:34:49 -0500 Received: from [84.231.43.47] by fep02-app.kolumbus.fi with ESMTP id <20060204172225.WIYU893.fep02-app.kolumbus.fi@[84.231.43.47]> for ; Sat, 4 Feb 2006 19:22:25 +0200 Message-ID: <43E4E30C.6070409@gmail.com> Date: Sat, 04 Feb 2006 19:23:24 +0200 From: "Jussi K. Virtanen" User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: SIMPLE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Simple] Purpose of the namespace field in MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 From simple-bounces@ietf.org Sun Feb 05 12:07:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5nMf-0005Gc-DS; Sun, 05 Feb 2006 12:07:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5nMe-0005GF-6f for simple@megatron.ietf.org; Sun, 05 Feb 2006 12:07:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25909 for ; Sun, 5 Feb 2006 12:06:02 -0500 (EST) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5nYU-0006KM-KX for simple@ietf.org; Sun, 05 Feb 2006 12:20:08 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id k15H7Udo211004 for ; Sun, 5 Feb 2006 17:07:30 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k15H7UaM240784 for ; Sun, 5 Feb 2006 18:07:30 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k15H7UBO005719 for ; Sun, 5 Feb 2006 18:07:30 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k15H7UtM005716 for ; Sun, 5 Feb 2006 18:07:30 +0100 To: Simple WG MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Avshalom Houri Message-ID: Date: Sun, 5 Feb 2006 19:07:28 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 | November 16, 2005) at 05/02/2006 19:07:29, Serialize complete at 05/02/2006 19:07:29 X-Spam-Score: 0.5 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Simple] Notifies on refreshes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============1015307965==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============1015307965== Content-Type: multipart/alternative; boundary="=_alternative 005DEFF4C225710C_=" This is a multipart message in MIME format. --=_alternative 005DEFF4C225710C_= Content-Type: text/plain; charset="US-ASCII" draft-niemi-sip-subnot-etags-00 takes an important step towards saving unneeded notifies when a subscription is refreshed. However, until the suggestion will be accepted and implemented I wonder what is the meaning of the following paragraph from 3265: 3.1.6.2. Confirmation of Subscription Creation/Refreshing Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY message immediately to communicate the current resource state to the subscriber. This NOTIFY message is sent on the same dialog as created by the SUBSCRIBE response. If the resource has no meaningful state at the time that the SUBSCRIBE message is processed, this NOTIFY message MAY contain an empty or neutral body. See section 3.2.2. for further details on NOTIFY message generation. What is the definition of *immediately* here? Can the NOTIFY wait until there is a next publish? --Avshalom --=_alternative 005DEFF4C225710C_= Content-Type: text/html; charset="US-ASCII"
draft-niemi-sip-subnot-etags-00 takes an important step towards saving unneeded
notifies when a subscription is refreshed.
However, until the suggestion will be accepted and implemented I wonder what is
the meaning of the following paragraph from 3265:

3.1.6.2. Confirmation of Subscription Creation/Refreshing

   Upon successfully accepting or refreshing a subscription, notifiers
   MUST send a NOTIFY message immediately to communicate the current
   resource state to the subscriber.  This NOTIFY message is sent on the
   same dialog as created by the SUBSCRIBE response.  If the resource
   has no meaningful state at the time that the SUBSCRIBE message is
   processed, this NOTIFY message MAY contain an empty or neutral body.
   See section 3.2.2. for further details on NOTIFY message generation.

What is the definition of *immediately* here? Can the NOTIFY wait until there
is a next publish?

--Avshalom
 --=_alternative 005DEFF4C225710C_=-- --===============1015307965== 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 --===============1015307965==-- From simple-bounces@ietf.org Sun Feb 05 16:38:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5rau-000779-JA; Sun, 05 Feb 2006 16:38:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5rat-00076J-Nr for simple@megatron.ietf.org; Sun, 05 Feb 2006 16:38:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16816 for ; Sun, 5 Feb 2006 16:37:12 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5rmx-00054k-F3 for simple@ietf.org; Sun, 05 Feb 2006 16:51:19 -0500 X-IronPort-AV: i="4.02,90,1139202000"; d="scan'208"; a="27620971:sNHT48397052" 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 Subject: RE: [Simple] IMDN issue #8: List-Action, Original-From and Original-Message-ID Date: Sun, 5 Feb 2006 16:38:51 -0500 Message-ID: <330A23D8336C0346B5C1A5BB196666470228F94F@ATLANTIS.Brooktrout.com> Thread-Topic: [Simple] IMDN issue #8: List-Action, Original-From and Original-Message-ID Thread-Index: AcYoKKhEG3VkfHqUSv+vNn/agrhZJACczqYw From: "Burger, Eric" To: "Hisham Khartabil" X-Spam-Score: 0.2 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: quoted-printable Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org It's too confusing to talk around an entirely new mechanism without folks seeing what that mechanism is. I thought we were going to publish the 'new' version and then discuss it. Rather than waiting, I just submitted draft-burger-simple-imdn-03. It should show up in the drafts archive shortly. Other stuff: A B2BUA is a B2BUA. When a User Agent Server gets a message, it is supposed to act like a User Agent Server. We give extra semantics for things with well defined action, like a list exploder or gateway. However, since we're changing what a UAS does with respect to SIP, we should not recreate the errors of the messaging past and leave that as "an exercise for the reader." Let's take the opportunity to "do the right thing" and let the endpoint figure out what *it* wants done. It is the owner of the request, after all. Gateways: If I know that Fred at AOL/MSN/Private-Enterprise-IM-system will never generate an IMDN, I do care that my message at least made it into the aether. Can't argue against this one if one argues for IMDN-as-transport-ACK mechanism. -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Thursday, February 02, 2006 1:44 PM To: Burger, Eric Cc: Simple WG Subject: Re: [Simple] IMDN issue #8: List-Action,Original-From and Original-Message-ID On Feb 2, 2006, at 6:05 PM, Burger, Eric wrote: > Yes, Original-* and List-Action could support the direct reporting from > the UAS to the UAC. However, they are necessary to solve a thorny > problem that B2BUA's introduce. Namely, by the strict definition of > delivery, the B2BUA MUST issue the IMDN, and that is the end of the > story. The B2BUA has no right to request a downstream IMDN, nor does=20 > it > have the right to relay the downstream IMDN back to the Requesting UAC. I disagree. That might be your definition of a B2BUA, not mine. How=20 could a B2BUA issue an IMDN to a IM it has no idea if it has been=20 delivered to a user or not. Especially if the IMDN is a read report. > > I agree the most common user interpretation of IMDN is that it is for > the final UAS, even through a gateway or exploder, to do the reporting. > HOWEVER, it is no the only case. Given that the plan below breaks the > definition of a UAS (the UAS half of a UAC) and it does not allow users > or intelligent agents who really only care if the message was processed > at the gateway or list exploder, I would offer that we use a mechanism > that works for all scenarios. Can you give real world examples of such scenarios where the sender=20 only cares that the GW or B2BUA has the message delivered to it. > > I would also offer the mechanism proposed in the text works for all > scenarios. Can you describe that mechanism to folks who don't have the privilage=20 of seeing the pending WG item version? > > [Note to Hisham - are you referring to the mechanism in > draft-burger-simple-imdn-01 or draft-ietf-simple imdn-00? I don't=20 > think > anyone has seen draft-ietf-simple-imdn-00 yet. The ietf-simple-imdn > mechanism is very different (although backwards compatible) with the > burger-simple-imdn mechanism.] I'm referring to burger-simple-imdn-01. We cannot just change=20 mechanisms without discussion on the mailing list, especially when the=20 draft is a WG item. Thanks, Hisham > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 > Behalf > Of Hisham Khartabil > Sent: Friday, January 27, 2006 10:19 AM > To: Simple WG > Subject: [Simple] IMDN issue #8: List-Action,Original-From and > Original-Message-ID > > I don't think the List-Action header is needed. The Original-From > header and Original-Message-ID may not be needed also. this depends on > how we define the behaviour of the IM exploder to be. > > To summarise: > > - List-Action header is used to indicate if a B2BUA or UAS is to do > the reporting > - Original-From allows a UAS to know there to send the notification if > there was a B2BUA like an exploder on the path. > - Original-Message-ID allows a UAS to indicate to the UAC the > message-ID of the original message that the notification is for. This > is also when a B2BUA is involved. > > All 3 headers are above to help the case that a UAC chooses for the UAS > to send the notifications directly instead of the B2BUA generating them > indicating the B2BUA's receipt of the message. > > I would design it as follows: > > - UAC indicates, in the IM, its wish to receive an IMDN > - B2BUA forwards the IM with the necessary original-from and > original-message-id headers (if needed) > - the UAS generates the IMDN and sends it just like it would send an IM > to the UAC. For MSRP, it would be just like a SEND request in the other > direction. For SIP MESSAGE, it would use the from (or original-from) > and to headers in the incoming IM to create the MESSAGE request in the > reverse direction. Same applies for message-id. > - If it was not possible for the B2BUA to reach the UAS, it would > generate its own IMDNs for that IM. > > Regards, > Hisham > > > _______________________________________________ > 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 Feb 06 04:33:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F62k8-0007oA-EU; Mon, 06 Feb 2006 04:33:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F62k6-0007o3-Mq for simple@megatron.ietf.org; Mon, 06 Feb 2006 04:33:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01603 for ; Mon, 6 Feb 2006 04:31:27 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F62wE-0002jF-Ru for simple@ietf.org; Mon, 06 Feb 2006 04:45:41 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id E5EA4194482 for ; Mon, 6 Feb 2006 10:32:45 +0100 (CET) Received: from [192.168.1.76] ([192.168.1.76]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Feb 2006 10:31:27 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=EUC-KR; format=flowed Message-Id: <64e613bc83e298cffaa8555b9764e8ba@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Simple] MSRP with Deferred-delivery Messaging Date: Mon, 6 Feb 2006 10:32:58 +0100 To: =?EUC-KR?Q?"=C0=CC=C0=E5=BF=F8"?= X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 06 Feb 2006 09:31:27.0612 (UTC) FILETIME=[1ACAA3C0:01C62B00] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Feb 3, 2006, at 5:02 PM, =C0=CC=C0=E5=BF=F8 wrote: > > Hi, everyone. > > My question is : > - MSRP is session-based. > - SMS/MMS is somewhat kind of page-mode messaging. > - Can MSRP support SMS/MMS nicely? What do you mean by support? Do you mean mimic the SMS/MMS service or=20 interwork through a GW? > > MSRP may be unsuitable for serving SMS/MMS, in particular, mobile=20 > environment. > > Most mobile handset cannot support multi-socket. > > Assuming that MSRP serves deferred-delivery messaging such as SMS/MMS, > resources(e.g. TCP connection) must quickly be released as soon as the=20= > completion of sending a message. > > But MSRP connection is released only if user actively performs BYE. > > Is there any method to quickly disconnect MSRP session without waiting=20= > for user's intervention > in the case of deferred-delivery(SMS/MMS)? > > Or, is MESSAGE-based mechanism more desirable for this case? Yes. Although some have showed interest in using MSRP for MMS like=20 service when the content of the message is large. Regards, Hisham > > --------------------------------------------------- > Jang-Won Lee / Senior > Data N/W Development Team, Network Group, KTF > M) +82-10-3010-1866 > L) +82-31-909-0670 > Fax) +82-31-909-0661 > --------------------------------------------------- > > > > _______________________________________________ > 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 Feb 06 04:39:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F62q8-0000Io-T5; Mon, 06 Feb 2006 04:39:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F62q6-0000IY-Ft for simple@megatron.ietf.org; Mon, 06 Feb 2006 04:39:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02047 for ; Mon, 6 Feb 2006 04:37:39 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F632G-0003kF-9f for simple@ietf.org; Mon, 06 Feb 2006 04:51:53 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id ACCC4194482 for ; Mon, 6 Feb 2006 10:39:04 +0100 (CET) Received: from [192.168.1.76] ([192.168.1.76]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Feb 2006 10:37:46 +0100 In-Reply-To: <330A23D8336C0346B5C1A5BB196666470228F94F@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB196666470228F94F@ATLANTIS.Brooktrout.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 Subject: Re: [Simple] IMDN issue #8: List-Action, Original-From and Original-Message-ID Date: Mon, 6 Feb 2006 10:39:17 +0100 To: "Burger, Eric" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 06 Feb 2006 09:37:46.0314 (UTC) FILETIME=[FC83FAA0:01C62B00] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Feb 5, 2006, at 10:38 PM, Burger, Eric wrote: > It's too confusing to talk around an entirely new mechanism without > folks seeing what that mechanism is. I thought we were going to > publish > the 'new' version and then discuss it. Rather than waiting, I just > submitted draft-burger-simple-imdn-03. It should show up in the drafts > archive shortly. > > Other stuff: > A B2BUA is a B2BUA. When a User Agent Server gets a message, it is > supposed to act like a User Agent Server. We give extra semantics for > things with well defined action, like a list exploder or gateway. > However, since we're changing what a UAS does with respect to SIP, we > should not recreate the errors of the messaging past and leave that as > "an exercise for the reader." Let's take the opportunity to "do the > right thing" and let the endpoint figure out what *it* wants done. It > is the owner of the request, after all. I still would like to see use cases here. I can't think of any. > > Gateways: If I know that Fred at AOL/MSN/Private-Enterprise-IM-system > will never generate an IMDN, I do care that my message at least made it > into the aether. Can't argue against this one if one argues for > IMDN-as-transport-ACK mechanism. How would u know? also, this is the gateways as well as AOL/MSN/Private-Enterprise-IM-system problem, not the user. Those protocols need to define their IMDN, otherwise IMDN cannot be reported back through the GW. Simple as that. What good is the information that the GW got it but not the end user??? Hisham > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Thursday, February 02, 2006 1:44 PM > To: Burger, Eric > Cc: Simple WG > Subject: Re: [Simple] IMDN issue #8: List-Action,Original-From and > Original-Message-ID > > > On Feb 2, 2006, at 6:05 PM, Burger, Eric wrote: > >> Yes, Original-* and List-Action could support the direct reporting > from >> the UAS to the UAC. However, they are necessary to solve a thorny >> problem that B2BUA's introduce. Namely, by the strict definition of >> delivery, the B2BUA MUST issue the IMDN, and that is the end of the >> story. The B2BUA has no right to request a downstream IMDN, nor does >> it >> have the right to relay the downstream IMDN back to the Requesting > UAC. > > I disagree. That might be your definition of a B2BUA, not mine. How > could a B2BUA issue an IMDN to a IM it has no idea if it has been > delivered to a user or not. Especially if the IMDN is a read report. > >> >> I agree the most common user interpretation of IMDN is that it is for >> the final UAS, even through a gateway or exploder, to do the > reporting. >> HOWEVER, it is no the only case. Given that the plan below breaks the >> definition of a UAS (the UAS half of a UAC) and it does not allow > users >> or intelligent agents who really only care if the message was > processed >> at the gateway or list exploder, I would offer that we use a mechanism >> that works for all scenarios. > > Can you give real world examples of such scenarios where the sender > only cares that the GW or B2BUA has the message delivered to it. > >> >> I would also offer the mechanism proposed in the text works for all >> scenarios. > > Can you describe that mechanism to folks who don't have the privilage > of seeing the pending WG item version? > >> >> [Note to Hisham - are you referring to the mechanism in >> draft-burger-simple-imdn-01 or draft-ietf-simple imdn-00? I don't >> think >> anyone has seen draft-ietf-simple-imdn-00 yet. The ietf-simple-imdn >> mechanism is very different (although backwards compatible) with the >> burger-simple-imdn mechanism.] > > I'm referring to burger-simple-imdn-01. We cannot just change > mechanisms without discussion on the mailing list, especially when the > draft is a WG item. > > Thanks, > Hisham > >> >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >> Behalf >> Of Hisham Khartabil >> Sent: Friday, January 27, 2006 10:19 AM >> To: Simple WG >> Subject: [Simple] IMDN issue #8: List-Action,Original-From and >> Original-Message-ID >> >> I don't think the List-Action header is needed. The Original-From >> header and Original-Message-ID may not be needed also. this depends on >> how we define the behaviour of the IM exploder to be. >> >> To summarise: >> >> - List-Action header is used to indicate if a B2BUA or UAS is to do >> the reporting >> - Original-From allows a UAS to know there to send the notification if >> there was a B2BUA like an exploder on the path. >> - Original-Message-ID allows a UAS to indicate to the UAC the >> message-ID of the original message that the notification is for. This >> is also when a B2BUA is involved. >> >> All 3 headers are above to help the case that a UAC chooses for the > UAS >> to send the notifications directly instead of the B2BUA generating > them >> indicating the B2BUA's receipt of the message. >> >> I would design it as follows: >> >> - UAC indicates, in the IM, its wish to receive an IMDN >> - B2BUA forwards the IM with the necessary original-from and >> original-message-id headers (if needed) >> - the UAS generates the IMDN and sends it just like it would send an > IM >> to the UAC. For MSRP, it would be just like a SEND request in the > other >> direction. For SIP MESSAGE, it would use the from (or original-from) >> and to headers in the incoming IM to create the MESSAGE request in the >> reverse direction. Same applies for message-id. >> - If it was not possible for the B2BUA to reach the UAS, it would >> generate its own IMDNs for that IM. >> >> Regards, >> Hisham >> >> >> _______________________________________________ >> 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 Feb 07 00:45:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Lfn-00057q-LX; Tue, 07 Feb 2006 00:45:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Lfi-00054r-Vt; Tue, 07 Feb 2006 00:45:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21484; Tue, 7 Feb 2006 00:44:02 -0500 (EST) Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Lrt-0000Tt-Mh; Tue, 07 Feb 2006 00:58:28 -0500 Received: from [192.168.0.103] (pool-70-104-24-36.dllstx.fios.verizon.net [70.104.24.36]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k175gLQA031340 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 6 Feb 2006 23:42:22 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <0B23EA50-279C-4548-B7F1-4CB334ABF93E@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "sip@ietf.org WG" , Sipping WG , "simple@ietf.org list" , sip-implementors@cs.columbia.edu From: Robert Sparks Date: Mon, 6 Feb 2006 23:42:23 -0600 X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (shaman.nostrum.com: 70.104.24.36 is authenticated by a trusted mechanism) X-Spam-Score: 3.0 (+++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: Subject: [Simple] 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 Tue Feb 07 06:51:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6RO1-0005HO-Og; Tue, 07 Feb 2006 06:51:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6RNz-0005Cs-32 for simple@megatron.ietf.org; Tue, 07 Feb 2006 06:51:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16795 for ; Tue, 7 Feb 2006 06:50:12 -0500 (EST) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6RaJ-0004uw-I2 for simple@ietf.org; Tue, 07 Feb 2006 07:04:41 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id k17BpgHm123624 for ; Tue, 7 Feb 2006 11:51:42 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k17Bpfjc223854 for ; Tue, 7 Feb 2006 12:51:41 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k17BpfCI020810 for ; Tue, 7 Feb 2006 12:51:41 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k17Bpf10020806 for ; Tue, 7 Feb 2006 12:51:41 +0100 To: Simple WG Subject: [Simple] Notifies on refreshes [Resend] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Avshalom Houri Message-ID: Date: Tue, 7 Feb 2006 13:51:40 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 | November 16, 2005) at 07/02/2006 13:51:41, Serialize complete at 07/02/2006 13:51:41 X-Spam-Score: 0.8 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============2072315499==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============2072315499== Content-Type: multipart/alternative; boundary="=_alternative 004102A1C225710E_=" This is a multipart message in MIME format. --=_alternative 004102A1C225710E_= Content-Type: text/plain; charset="US-ASCII" draft-niemi-sip-subnot-etags-00 takes an important step towards saving unneeded notifies when a subscription is refreshed. However, until the suggestion will be accepted and implemented I wonder what is the meaning of the following paragraph from 3265: 3.1.6.2. Confirmation of Subscription Creation/Refreshing Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY message immediately to communicate the current resource state to the subscriber. This NOTIFY message is sent on the same dialog as created by the SUBSCRIBE response. If the resource has no meaningful state at the time that the SUBSCRIBE message is processed, this NOTIFY message MAY contain an empty or neutral body. See section 3.2.2. for further details on NOTIFY message generation. What is the definition of *immediately* here? Can the NOTIFY wait until there is a next publish? --Avshalom --=_alternative 004102A1C225710E_= Content-Type: text/html; charset="US-ASCII"


draft-niemi-sip-subnot-etags-00 takes an important step towards saving unneeded
notifies when a subscription is refreshed.
However, until the suggestion will be accepted and implemented I wonder what is
the meaning of the following paragraph from 3265:

3.1.6.2. Confirmation of Subscription Creation/Refreshing

   Upon successfully accepting or refreshing a subscription, notifiers
   MUST send a NOTIFY message immediately to communicate the current
   resource state to the subscriber.  This NOTIFY message is sent on the
   same dialog as created by the SUBSCRIBE response.  If the resource
   has no meaningful state at the time that the SUBSCRIBE message is
   processed, this NOTIFY message MAY contain an empty or neutral body.
   See section 3.2.2. for further details on NOTIFY message generation.

What is the definition of *immediately* here? Can the NOTIFY wait until there
is a next publish?

--Avshalom
--=_alternative 004102A1C225710E_=-- --===============2072315499== 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 --===============2072315499==-- From simple-bounces@ietf.org Tue Feb 07 07:59:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6SRn-0000I9-Ih; Tue, 07 Feb 2006 07:59:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6SRm-0000Ay-Ep for simple@megatron.ietf.org; Tue, 07 Feb 2006 07:59:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22518 for ; Tue, 7 Feb 2006 07:58:06 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Se2-0007DX-TV for simple@ietf.org; Tue, 07 Feb 2006 08:12:36 -0500 Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IUB008YPIR6QH@mailout2.samsung.com> for simple@ietf.org; Tue, 07 Feb 2006 21:59:30 +0900 (KST) Received: from samsungk1o0rnf ([105.253.11.1]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IUB008NXIR2B5@mmp2.samsung.com> for simple@ietf.org; Tue, 07 Feb 2006 21:59:30 +0900 (KST) Date: Tue, 07 Feb 2006 21:58:24 +0900 From: Jaekwon Oh To: jonathan Rosenberg Message-id: <00de01c62be6$30d9cb50$a0020a0a@samsungk1o0rnf> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Simple WG Subject: [Simple] Other MIME type than xcap-el/attr X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============1994268863==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1994268863== Content-type: multipart/alternative; boundary="Boundary_(ID_jBOqGxMLxfSWExFDVFiCWQ)" This is a multi-part message in MIME format. --Boundary_(ID_jBOqGxMLxfSWExFDVFiCWQ) Content-type: text/plain; charset=ks_c_5601-1987 Content-Transfer-Encoding: 7BIT Hello Jonathan and all, One quick question on XCAP-08. Does XCAP allows to extend xcap-el/attr MIME Type for the fragement containing element/attrs? In other words, does XCAP allows to use other MIME Type than xcap-el/attr for the element/attr fragment? According to XCAP-08 texts, it seems not allowed; the text says that it 'MUST' use such MIME Type. Thank you in advance. BR, Jaekwon Oh Global Stanadards & Research Samsung Electronics, Co. Ltd. TEL +82 31 279 5086 CP +82 16 9530 5086 FAX +82 31 279 5130 jaekwon.oh@samsung.com --Boundary_(ID_jBOqGxMLxfSWExFDVFiCWQ) Content-type: text/html; charset=ks_c_5601-1987 Content-Transfer-Encoding: 7BIT
Hello Jonathan and all,
 
One quick question on XCAP-08.
Does XCAP allows to extend xcap-el/attr MIME Type for the fragement containing element/attrs?
In other words, does XCAP allows to use other MIME Type than xcap-el/attr for the element/attr fragment?
According to XCAP-08 texts, it seems not allowed; the text says that it 'MUST' use such MIME Type.
Thank you in advance.
 
BR,
Jaekwon Oh
 
Global Stanadards & Research
Samsung Electronics, Co. Ltd.
TEL  +82 31 279 5086
CP   +82 16 9530 5086
FAX  +82 31 279 5130
jaekwon.oh@samsung.com
 
 
--Boundary_(ID_jBOqGxMLxfSWExFDVFiCWQ)-- --===============1994268863== 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 --===============1994268863==-- From simple-bounces@ietf.org Wed Feb 08 06:21:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6nOI-0003rF-RJ; Wed, 08 Feb 2006 06:21:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6nOH-0003pO-CS for simple@megatron.ietf.org; Wed, 08 Feb 2006 06:21:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12667 for ; Wed, 8 Feb 2006 06:19:59 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6nap-000068-PS for simple@ietf.org; Wed, 08 Feb 2006 06:34:41 -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 k18BLKs2028045; Wed, 8 Feb 2006 13:21:20 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Feb 2006 13:21:34 +0200 Received: from [172.21.38.199] ([172.21.38.199]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 8 Feb 2006 13:21:34 +0200 Message-ID: <43E9D43D.8010807@nokia.com> Date: Wed, 08 Feb 2006 13:21:33 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Avshalom Houri Subject: Re: [Simple] Notifies on refreshes [Resend] References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Feb 2006 11:21:34.0319 (UTC) FILETIME=[D1859FF0:01C62CA1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, ext Avshalom Houri wrote: > draft-niemi-sip-subnot-etags-00 takes an important step towards saving > unneeded > notifies when a subscription is refreshed. Thanks. ;) > However, until the suggestion will be accepted and implemented I wonder > what is > the meaning of the following paragraph from 3265: > > 3.1.6.2. Confirmation of Subscription Creation/Refreshing > > Upon successfully accepting or refreshing a subscription, notifiers > MUST send a NOTIFY message immediately to communicate the current > resource state to the subscriber. This NOTIFY message is sent on the > same dialog as created by the SUBSCRIBE response. If the resource > has no meaningful state at the time that the SUBSCRIBE message is > processed, this NOTIFY message MAY contain an empty or neutral body. > See section 3.2.2. for further details on NOTIFY message generation. > > What is the definition of *immediately* here? Can the NOTIFY wait until > there > is a next publish? My reading of it is that the NOTIFY is sent immediately after the 2xx; the 1st notify can of course contain dummy state, or no state at all. What's important is that the dialog is confirmed and the state of the subscription is communicated with the NOTIFY and Subscription-State header field. I'm not sure how delaying the sending of the initial state would help here, especially if the subscriber really needs that initial state. After all, it wouldn't be subscribing if it didn't. Cheers, Aki > --Avshalom > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Feb 08 06:31:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6nXe-0001If-NP; Wed, 08 Feb 2006 06:31:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6nXd-0001HU-EX for simple@megatron.ietf.org; Wed, 08 Feb 2006 06:31:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13319 for ; Wed, 8 Feb 2006 06:29:32 -0500 (EST) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6nk2-0000PQ-8S for simple@ietf.org; Wed, 08 Feb 2006 06:44:13 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id k18BUxVV263064 for ; Wed, 8 Feb 2006 11:30:59 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k18BUxKK240844 for ; Wed, 8 Feb 2006 12:30:59 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k18BUxtU014885 for ; Wed, 8 Feb 2006 12:30:59 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k18BUxSX014880; Wed, 8 Feb 2006 12:30:59 +0100 In-Reply-To: <43E9D43D.8010807@nokia.com> To: Aki Niemi Subject: Re: [Simple] Notifies on refreshes [Resend] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Avshalom Houri Message-ID: Date: Wed, 8 Feb 2006 13:30:58 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 | November 16, 2005) at 08/02/2006 13:30:58, Serialize complete at 08/02/2006 13:30:58 X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 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="===============1357266462==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============1357266462== Content-Type: multipart/alternative; boundary="=_alternative 003F191FC225710F_=" This is a multipart message in MIME format. --=_alternative 003F191FC225710F_= Content-Type: text/plain; charset="US-ASCII" Hi Aki, The issue is more with refreshes where we need to send a refresh with a state where the subscriber does not really need it. It is a big burden on the presence server and on the subscriber. If the subscriber supports partial notify we could send an empty notify indicating that nothing was changed (with version) but not all subscribers will support partial notifies. --Avshalom Aki Niemi 08/02/2006 13:21 To Avshalom Houri/Haifa/IBM@IBMIL cc Simple WG Subject Re: [Simple] Notifies on refreshes [Resend] Hi, ext Avshalom Houri wrote: > draft-niemi-sip-subnot-etags-00 takes an important step towards saving > unneeded > notifies when a subscription is refreshed. Thanks. ;) > However, until the suggestion will be accepted and implemented I wonder > what is > the meaning of the following paragraph from 3265: > > 3.1.6.2. Confirmation of Subscription Creation/Refreshing > > Upon successfully accepting or refreshing a subscription, notifiers > MUST send a NOTIFY message immediately to communicate the current > resource state to the subscriber. This NOTIFY message is sent on the > same dialog as created by the SUBSCRIBE response. If the resource > has no meaningful state at the time that the SUBSCRIBE message is > processed, this NOTIFY message MAY contain an empty or neutral body. > See section 3.2.2. for further details on NOTIFY message generation. > > What is the definition of *immediately* here? Can the NOTIFY wait until > there > is a next publish? My reading of it is that the NOTIFY is sent immediately after the 2xx; the 1st notify can of course contain dummy state, or no state at all. What's important is that the dialog is confirmed and the state of the subscription is communicated with the NOTIFY and Subscription-State header field. I'm not sure how delaying the sending of the initial state would help here, especially if the subscriber really needs that initial state. After all, it wouldn't be subscribing if it didn't. Cheers, Aki > --Avshalom > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple --=_alternative 003F191FC225710F_= Content-Type: text/html; charset="US-ASCII"
Hi Aki,

The issue is more with refreshes where we need to send a refresh with
a state where the subscriber does not really need it.
It is a big burden on the presence server and on the subscriber.

If the subscriber supports partial notify we could send an empty notify
indicating that nothing was changed (with version) but not all subscribers
will support partial notifies.

--Avshalom


Aki Niemi <aki.niemi@nokia.com>

08/02/2006 13:21

To
Avshalom Houri/Haifa/IBM@IBMIL
cc
Simple WG <simple@ietf.org>
Subject
Re: [Simple] Notifies on refreshes [Resend]





Hi,

ext Avshalom Houri wrote:
> draft-niemi-sip-subnot-etags-00 takes an important step towards saving
> unneeded
> notifies when a subscription is refreshed.

Thanks. ;)

> However, until the suggestion will be accepted and implemented I wonder
> what is
> the meaning of the following paragraph from 3265:
>
> 3.1.6.2. Confirmation of Subscription Creation/Refreshing
>
>    Upon successfully accepting or refreshing a subscription, notifiers
>    MUST send a NOTIFY message immediately to communicate the current
>    resource state to the subscriber.  This NOTIFY message is sent on the
>    same dialog as created by the SUBSCRIBE response.  If the resource
>    has no meaningful state at the time that the SUBSCRIBE message is
>    processed, this NOTIFY message MAY contain an empty or neutral body.
>    See section 3.2.2. for further details on NOTIFY message generation.
>
> What is the definition of *immediately* here? Can the NOTIFY wait until
> there
> is a next publish?

My reading of it is that the NOTIFY is sent immediately after the 2xx;
the 1st notify can of course contain dummy state, or no state at all.
What's important is that the dialog is confirmed and the state of the
subscription is communicated with the NOTIFY and Subscription-State
header field.

I'm not sure how delaying the sending of the initial state would help
here, especially if the subscriber really needs that initial state.
After all, it wouldn't be subscribing if it didn't.

Cheers,
Aki

> --Avshalom
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
--=_alternative 003F191FC225710F_=-- --===============1357266462== 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 --===============1357266462==-- From simple-bounces@ietf.org Wed Feb 08 07:01:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6o16-0006iw-FI; Wed, 08 Feb 2006 07:01:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6o14-0006iI-SH for simple@megatron.ietf.org; Wed, 08 Feb 2006 07:01:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15522 for ; Wed, 8 Feb 2006 06:59:57 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6oDW-0001TA-4z for simple@ietf.org; Wed, 08 Feb 2006 07:14:39 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k18C1G3X030731; Wed, 8 Feb 2006 14:01:21 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Feb 2006 14:01:26 +0200 Received: from [172.21.38.199] ([172.21.38.199]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 8 Feb 2006 14:01:26 +0200 Message-ID: <43E9DD94.40001@nokia.com> Date: Wed, 08 Feb 2006 14:01:24 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Avshalom Houri Subject: Re: [Simple] Notifies on refreshes [Resend] References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Feb 2006 12:01:26.0149 (UTC) FILETIME=[6329EB50:01C62CA7] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext Avshalom Houri wrote: > > Hi Aki, > > The issue is more with refreshes where we need to send a refresh with > a state where the subscriber does not really need it. > It is a big burden on the presence server and on the subscriber. I see, then this is what subnot-etags is attempting to solve. The server can't tell if it can delay the NOTIFY, unless there is a mechanism like the one described in the subnot-etags draft. > If the subscriber supports partial notify we could send an empty notify > indicating that nothing was changed (with version) but not all subscribers > will support partial notifies. True. But again, the server needs to know whether there is a previous (full) state at the client to which it can create a state differential, or partial notify. All in all, to be able to suppress the notify payload, we need subnot-etags (or something similar). Cheers, Aki > --Avshalom > > > > *Aki Niemi * > > 08/02/2006 13:21 > > > To > Avshalom Houri/Haifa/IBM@IBMIL > cc > Simple WG > Subject > Re: [Simple] Notifies on refreshes [Resend] > > > > > > > > > Hi, > > ext Avshalom Houri wrote: > > draft-niemi-sip-subnot-etags-00 takes an important step towards saving > > unneeded > > notifies when a subscription is refreshed. > > Thanks. ;) > > > However, until the suggestion will be accepted and implemented I wonder > > what is > > the meaning of the following paragraph from 3265: > > > > 3.1.6.2. Confirmation of Subscription Creation/Refreshing > > > > Upon successfully accepting or refreshing a subscription, notifiers > > MUST send a NOTIFY message immediately to communicate the current > > resource state to the subscriber. This NOTIFY message is sent on the > > same dialog as created by the SUBSCRIBE response. If the resource > > has no meaningful state at the time that the SUBSCRIBE message is > > processed, this NOTIFY message MAY contain an empty or neutral body. > > See section 3.2.2. for further details on NOTIFY message generation. > > > > What is the definition of *immediately* here? Can the NOTIFY wait until > > there > > is a next publish? > > My reading of it is that the NOTIFY is sent immediately after the 2xx; > the 1st notify can of course contain dummy state, or no state at all. > What's important is that the dialog is confirmed and the state of the > subscription is communicated with the NOTIFY and Subscription-State > header field. > > I'm not sure how delaying the sending of the initial state would help > here, especially if the subscriber really needs that initial state. > After all, it wouldn't be subscribing if it didn't. > > Cheers, > Aki > > > --Avshalom > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 08 08:57:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6pou-0005Oe-UP; Wed, 08 Feb 2006 08:57:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6pos-0005Ng-Nl for simple@megatron.ietf.org; Wed, 08 Feb 2006 08:57:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24413 for ; Wed, 8 Feb 2006 08:55:26 -0500 (EST) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6q1H-0005Wh-T1 for simple@ietf.org; Wed, 08 Feb 2006 09:10:10 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k18Dv1g0015551; Wed, 8 Feb 2006 15:57:03 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Feb 2006 15:57:03 +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 Feb 2006 15:57:03 +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 k18Durs03655; Wed, 8 Feb 2006 15:56:53 +0200 (EET) Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145]) by kusti.research.nokia.com (Postfix) with ESMTP id 3F40E93B75; Wed, 8 Feb 2006 15:56:53 +0200 (EET) Message-ID: <43E9F8A5.6030805@nokia.com> Date: Wed, 08 Feb 2006 15:56:53 +0200 From: Jari Urpalainen User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Stephane Bortzmeyer References: <20060206220115.GA201@preston.sources.org> In-Reply-To: <20060206220115.GA201@preston.sources.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Feb 2006 13:57:03.0945 (UTC) FILETIME=[8A699390:01C62CB7] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: [Simple] Re: draft-xml-patch and the comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Thanks, for your comments, more inline, I'll respond to each of your comments here. ext Stephane Bortzmeyer wrote: >[I'm not a member of SIMPLE - I'm interested in XML but not in SIP - >so please keep me informed if you choose to reply.] > >I've just studied draft-ietf-simple-xml-patch-ops-01 and I have a few >remarks. First, the insertion of comments: > > An example for an addition of a comment node: > > > >IMHO, this is not good XML. A XML parser does not have to pass the >comments to the application (the specification says "They are not part >of the document's character data; an XML processor MAY, but need not, >make it possible for an application to retrieve the text of >comments."). > >And writing it that way makes difficult to add comments in patches: > > > > > > >I would suggest something which is more XML and consistent with the >way XSLT does it: a element. > > > > This is to be added in the resulting XML file > > > So you say XPath, c14n etc. are evil, bad xml ;-). This is to be used with "real" libraries, on open source implementation which uses libxml2 happily supports full XPath 1.0, although a small subset of XPath 1.0 is needed here. So if the XML parser doesn't support these it can't do that for XPath or c14n either. Also e.g. a proper CDATA/entity/character reference handling may be rather difficult/clumsy. Anyhow, it is probably worth mentioning in the i-d. btw. the opensource implementation will be updated shortly, and hopefully i can include an auto diff tool as well. >I have a few suggestions for the Security Considerations section: > >Since a patch can potentially delete valuable information, >implementations should take care of authenticating the patches before >applying them, for instance with XML signature [RFC 3275] or transport >security, such as HTTP authentication [RFC 2617] if the patch is >served with HTTP. > >In addition, an implementation MAY choose to limit what a patch can >do, by forbidding some operations such as or and/or >by limiting the amount of changes that can be done. > > > > As you have noticed this i-d is a framework which doesn't define a Mime-Type, so it needs additional specs that include these type definitions. The whole text in security part is thus "hand waving" as the including spec defines these finally. Also e.g. authorization policy is really beyond the scope. >For consistency, I suggest adding a "append" option to the >. It is the default, but, IMHO, it should >be made explicit, for instance to allow patch authors to clearly state >thay they want to append. > > > Well, I had this psvi like feature in the previous version, but this is indeed a bad habit, one of those things that come from the w3c schema language. >AFAIK, it is not specified what to do if one patch raises an error >while the previous patches in a were OK. I suggest to add to >section 5 "Error Handling" something like: > >The patches in a element are all applied with success or none is >applied. An implementation MUST NOT produce a XML document which >results from a partial application of the patches. > >An implementation MAY continue the patching after an error (to produce >diagnostics, for instance), but, since the selectors are applied to >the XML document already patched, these diagnostics are of doubtful >value. > > The sentence "It is an error condition if any of the given operations can not be unambiguously fulfilled." is supposed to explicitly state this. So some elaboration is needed, I assume. >And one remark that may be offtopic: why W3C Schemas and not RelaxNG, >which I much prefer (see RFC 4287 for an example)? > > I'll absolutely agree (and undoubtedly I've made noise about RNG many times). However, there's quite a lot inertia in this case as many content models are described with the w3c schema language here. Also in this particular case even the w3c schema can do its task quite well (which is not generally true). I've been thinking about adding also rng schema to this, so that both were informative just like in atom format. Thanks, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 08 16:58:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6xKG-00025m-Eb; Wed, 08 Feb 2006 16:58:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6xKD-000228-36 for simple@megatron.ietf.org; Wed, 08 Feb 2006 16:58:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07597 for ; Wed, 8 Feb 2006 16:56:26 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6xWr-0007n5-Vw for simple@ietf.org; Wed, 08 Feb 2006 17:11:15 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 08 Feb 2006 13:57:59 -0800 X-IronPort-AV: i="4.02,98,1139212800"; d="scan'208"; a="1774686750:sNHT30529652" 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 k18LvnWP023219; Wed, 8 Feb 2006 13:57:57 -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); Wed, 8 Feb 2006 16:57:54 -0500 Received: from [64.102.206.201] ([64.102.206.201]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 16:57:54 -0500 Message-ID: <43EA6962.5010004@cisco.com> Date: Wed, 08 Feb 2006 16:57:54 -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: Jaekwon Oh References: <00de01c62be6$30d9cb50$a0020a0a@samsungk1o0rnf> In-Reply-To: <00de01c62be6$30d9cb50$a0020a0a@samsungk1o0rnf> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Feb 2006 21:57:54.0686 (UTC) FILETIME=[B6CB49E0:01C62CFA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: [Simple] Re: Other MIME type than xcap-el/attr X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The intent was that its not meant to be extended, and that nothing else would be used. Do you have a use case or need for something else? Thanks, Jonathan R. Jaekwon Oh wrote: > Hello Jonathan and all, > > One quick question on XCAP-08. > Does XCAP allows to extend xcap-el/attr MIME Type for the fragement > containing element/attrs? > In other words, does XCAP allows to use other MIME Type than > xcap-el/attr for the element/attr fragment? > According to XCAP-08 texts, it seems not allowed; the text says that it > 'MUST' use such MIME Type. > Thank you in advance. > > BR, > Jaekwon Oh > > Global Stanadards & Research > Samsung Electronics, Co. Ltd. > TEL +82 31 279 5086 > CP +82 16 9530 5086 > FAX +82 31 279 5130 > jaekwon.oh@samsung.com > > -- 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 Feb 08 23:44:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F73fe-0007p2-Om; Wed, 08 Feb 2006 23:44:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F73fc-0007fl-90 for simple@megatron.ietf.org; Wed, 08 Feb 2006 23:44:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14558 for ; Wed, 8 Feb 2006 23:42:48 -0500 (EST) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F73s9-0006g8-Q9 for simple@ietf.org; Wed, 08 Feb 2006 23:57:40 -0500 X-IronPort-AV: i="4.02,99,1139202000"; d="scan'208"; a="27876463:sNHT26950656" 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, 8 Feb 2006 23:44:24 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664702331C89@ATLANTIS.Brooktrout.com> Thread-Topic: IMDN Thread-Index: AcYtM4AGuJJTzUH2Tcux1GuMQXV8Lg== From: "Burger, Eric" To: "Simple WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: quoted-printable Subject: [Simple] 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Some of the stuff I've been talking about may make more sense with the text in front of you. Check out: http://www.ietf.org/internet-drafts/draft-burger-simple-imdn-03.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 09 03:23:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F775g-0007Xn-46; Thu, 09 Feb 2006 03:23:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6OV0-0003Ij-Cp for simple@megatron.ietf.org; Tue, 07 Feb 2006 03:46:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04019 for ; Tue, 7 Feb 2006 03:45:06 -0500 (EST) From: Silvestr.Peknik@tietoenator.com Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6OhA-0006g4-V9 for simple@ietf.org; Tue, 07 Feb 2006 03:59:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Feb 2006 09:46:22 +0100 Message-ID: <3ACC9A25264A684F82C71840111F9798011686CC@carrera.eu.tieto.com> Thread-Topic: partial publications processing Thread-Index: AcYrwvj08FoyuWXYQQeVItdNl17KsQ== To: X-OriginalArrivalTime: 07 Feb 2006 08:46:24.0676 (UTC) FILETIME=[FA211640:01C62BC2] X-Spam-Score: 0.5 (/) X-Scan-Signature: 9a9ddb14fac983e71b59f23b52a45b4e X-Mailman-Approved-At: Thu, 09 Feb 2006 03:23:45 -0500 Subject: [Simple] partial publications processing X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============1589023428==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1589023428== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62BC2.F9571962" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62BC2.F9571962 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello,=20 =20 I am trying to find out how partial publication processing should work. In draft-ietf-simple-partial-publish-03, par. 4.2 (Generation of Partial Publications) is written: ... o The document in the body of the request is populated with a root element that includes the 'entity' attribute set to identify the presentity, and a 'version' attribute that MUST be initialized by setting it to one. ... =20 In par. 4.3.1 (Processing of Partial Publications) is written: ... o The compositor MUST initialize its local version counter, and set it to the 'version' attribute value of the element. ... =20 =20 The "server part" does not state that the initial publication must have version 1, while "client part" does. My understanding is that the server should not care about the version number in the initial publication, and should accept it even if the version is not 1. Is it correct? =20 This problem leads to another, more general - I am not sure how to interpret "client" and "server" parts of IETF specifications. If some specification states that client MUST do something (e.g. set the version number to 1 as in this example), does it affect the server behavior - so the server MUST check if the version is 1? Or is client and server part "separate", so if the "server" part does not state that the server MUST check it (the version number, in this example), then the server does not check it ... =20 Could someone bring light to this problem please? =20 Thank you, =20 Silvestr Peknik Software Specialist =20 TietoEnator Czech Software Center Phone +420 599 096 027 E-mail silvestr.peknik@tietoenator.com =20 =20 Vystavni 292/13 CZ-709 16 Ostrava =20 www.tietoenator.com =20 =20 ------_=_NextPart_001_01C62BC2.F9571962 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I am trying to find out how partial publication = processing should work. In draft-ietf-simple-partial-publish-03, par. 4.2 = (Generation of Partial Publications) is written:

…

  o  The document in the body of the = request is populated with a <pidf-

      full> root element = that includes the 'entity' attribute set to

      identify the = presentity, and a 'version' attribute that MUST be

      initialized by setting = it to one.

…

 

In par. 4.3.1 (Processing of Partial = Publications) is written:

…

  o  The compositor MUST initialize its = local version counter, and set

      it to the 'version' = attribute value of the <pidf-full> element.

…

 

 

The “server part” does not state that the initial publication must have version 1, while “client part” = does. My understanding is that the server should not care about the version = number in the initial publication, and should accept it even if the version is not = 1. Is it correct?

 

This problem leads to another, more general – I = am not sure how to interpret “client” and “server” = parts of IETF specifications. If some specification states that client MUST do = something (e.g. set the version number to 1 as in this example), does it affect = the server behavior – so the server MUST check if the version is 1? Or = is client and server part “separate”, so if the = “server” part does not state that the server MUST check it (the version number, = in this example), then the server does not check it = …

 

Could someone bring light to this problem = please?

 

Thank you,

 

Silvestr = Peknik

=

Software = Specialist

=

=  

= TietoEnator

=

Czech Software Center

=

Phone +420 599 096 = 027

=

E-mail silvestr.peknik@tietoenator.com  

=

 

Vystavni = 292/13

=

CZ-709 16 = Ostrava=

=

 

www.tietoenator.com

=

 

------_=_NextPart_001_01C62BC2.F9571962-- --===============1589023428== 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 --===============1589023428==-- From simple-bounces@ietf.org Thu Feb 09 03:23:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F775h-0007YH-3T; Thu, 09 Feb 2006 03:23:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6upC-0001B4-8q; Wed, 08 Feb 2006 14:17:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23379; Wed, 8 Feb 2006 14:16:16 -0500 (EST) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6v1p-0001R3-IH; Wed, 08 Feb 2006 14:31:03 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k18JHUqv024751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Feb 2006 11:17:31 -0800 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k18JHSLQ000775; Wed, 8 Feb 2006 11:17:29 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4374E21F.7000702@cs.columbia.edu> <3AF54F1A-E276-400E-B3AA-E884330BCDC1@hxr.us> <4378F0C6.3060600@cs.columbia.edu> <1D73DF6B-1812-4C7B-9EF2-4A74EF1B20DD@hxr.us> <437902EC.1040901@cs.columbia.edu> <32264ECE-58EC-4FE0-B82B-A27306754226@hxr.us> <43792C92.9060509@cs.columbia.edu> <39D41869-8947-4CB8-9C42-CA719AE66A29@hxr.us> <43BD4CD6.50400@cs.columbia.edu> <1F8DEA0A-674E-4DBC-87D6-3F4CCFD73A81@hxr.us> <43BE3ADB.2020305@cs.columbia.edu> <1FEECD6E-CFF0-4E87-A819-E0AFD4847CA1@hxr.us> <43BE7D46.1030908@cs.columbia.edu> <43BE94BD.9010507@cs.columbia.edu> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 8 Feb 2006 11:10:04 -0800 To: Geopriv WG , Simple WG From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-Mailman-Approved-At: Thu, 09 Feb 2006 03:23:45 -0500 Cc: Allison Mankin , Henning Schulzrinne Subject: [Simple] Re: [Geopriv] Domain identifier in common 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org At 6:00 PM -0800 1/13/06, Randall Gellens wrote: > Please reply by Friday January 20 if you feel strongly that we need > to add the restriction: "Common policy MUST use UTF-8 to store > domain names in 'id' domain attributes". If there is no consensus > to add this restriction, we won't. Just to follow-up: no messages were sent to the list supporting the UTF-8 only restriction. Therefore, there is *NO* consensus that "Common policy MUST use UTF-8 to store domain names in 'id' domain attributes". Hence, this restriction won't be added. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 09 03:23:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F775h-0007Yh-Qj; Thu, 09 Feb 2006 03:23:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6EUN-0001op-QT for simple@megatron.ietf.org; Mon, 06 Feb 2006 17:05:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09627 for ; Mon, 6 Feb 2006 17:03:55 -0500 (EST) Received: from ns2.netaktiv.com ([80.67.170.3] helo=soyouz2.netaktiv.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6EgV-0004rk-At for simple@ietf.org; Mon, 06 Feb 2006 17:18:16 -0500 Received: from localhost (soyouz2 [127.0.0.1]) by soyouz2.netaktiv.com (Postfix) with ESMTP id CF427A7BC3; Mon, 6 Feb 2006 23:05:09 +0100 (CET) Received: from soyouz2.netaktiv.com ([127.0.0.1]) by localhost (soyouz2 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18738-45; Mon, 6 Feb 2006 23:05:08 +0100 (CET) Received: by soyouz2.netaktiv.com (Postfix, from userid 10) id 3007EA7AF6; Mon, 6 Feb 2006 23:05:08 +0100 (CET) Received: from preston.sources.org (preston [172.19.1.2]) by mail.sources.org (Postfix) with ESMTP id DCF21117D9; Mon, 6 Feb 2006 23:01:18 +0100 (CET) Received: by preston.sources.org (Postfix, from userid 1000) id E9C2AAAF29; Mon, 6 Feb 2006 23:01:15 +0100 (CET) Date: Mon, 6 Feb 2006 23:01:15 +0100 From: Stephane Bortzmeyer To: Jari Urpalainen Message-ID: <20060206220115.GA201@preston.sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: NetBSD 3.0_STABLE sparc64 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at netaktiv.com X-Spam-Score: 0.5 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Thu, 09 Feb 2006 03:23:45 -0500 Cc: bortzmeyer@nic.fr, simple@ietf.org Subject: [Simple] draft-xml-patch and the comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org [I'm not a member of SIMPLE - I'm interested in XML but not in SIP - so please keep me informed if you choose to reply.] I've just studied draft-ietf-simple-xml-patch-ops-01 and I have a few remarks. First, the insertion of comments: An example for an addition of a comment node: IMHO, this is not good XML. A XML parser does not have to pass the comments to the application (the specification says "They are not part of the document's character data; an XML processor MAY, but need not, make it possible for an application to retrieve the text of comments."). And writing it that way makes difficult to add comments in patches: I would suggest something which is more XML and consistent with the way XSLT does it: a element. This is to be added in the resulting XML file _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 09 03:23:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F775i-0007Z9-I1; Thu, 09 Feb 2006 03:23:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6EYu-0002So-4o for simple@megatron.ietf.org; Mon, 06 Feb 2006 17:10:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09958 for ; Mon, 6 Feb 2006 17:08:32 -0500 (EST) Received: from soyouz2.netaktiv.com ([80.67.170.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6El1-00056X-Qn for simple@ietf.org; Mon, 06 Feb 2006 17:22:53 -0500 Received: from localhost (soyouz2 [127.0.0.1]) by soyouz2.netaktiv.com (Postfix) with ESMTP id BFEBBA7BC3; Mon, 6 Feb 2006 23:10:09 +0100 (CET) Received: from soyouz2.netaktiv.com ([127.0.0.1]) by localhost (soyouz2 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24046-16; Mon, 6 Feb 2006 23:10:08 +0100 (CET) Received: by soyouz2.netaktiv.com (Postfix, from userid 10) id 6172DA7AF6; Mon, 6 Feb 2006 23:10:08 +0100 (CET) Received: from preston.sources.org (preston [172.19.1.2]) by mail.sources.org (Postfix) with ESMTP id 81F6E11B30; Mon, 6 Feb 2006 23:09:39 +0100 (CET) Received: by preston.sources.org (Postfix, from userid 1000) id 48E89AAE05; Mon, 6 Feb 2006 23:09:39 +0100 (CET) Date: Mon, 6 Feb 2006 23:09:39 +0100 From: Stephane Bortzmeyer To: Jari Urpalainen Message-ID: <20060206220939.GA750@preston.sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: NetBSD 3.0_STABLE sparc64 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at netaktiv.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-Mailman-Approved-At: Thu, 09 Feb 2006 03:23:45 -0500 Cc: bortzmeyer@nic.fr, simple@ietf.org Subject: [Simple] draft-xml-patch and the security X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I have a few suggestions for the Security Considerations section: Since a patch can potentially delete valuable information, implementations should take care of authenticating the patches before applying them, for instance with XML signature [RFC 3275] or transport security, such as HTTP authentication [RFC 2617] if the patch is served with HTTP. In addition, an implementation MAY choose to limit what a patch can do, by forbidding some operations such as or and/or by limiting the amount of changes that can be done. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 09 03:23:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F775j-0007Zd-FF; Thu, 09 Feb 2006 03:23:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Edj-0004Qk-K5 for simple@megatron.ietf.org; Mon, 06 Feb 2006 17:15:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11389 for ; Mon, 6 Feb 2006 17:13:31 -0500 (EST) Received: from ns2.netaktiv.com ([80.67.170.3] helo=soyouz2.netaktiv.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Epr-0005nn-IU for simple@ietf.org; Mon, 06 Feb 2006 17:27:52 -0500 Received: from localhost (soyouz2 [127.0.0.1]) by soyouz2.netaktiv.com (Postfix) with ESMTP id 6D709A7BC5; Mon, 6 Feb 2006 23:15:09 +0100 (CET) Received: from soyouz2.netaktiv.com ([127.0.0.1]) by localhost (soyouz2 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24046-18; Mon, 6 Feb 2006 23:15:08 +0100 (CET) Received: by soyouz2.netaktiv.com (Postfix, from userid 10) id 03E56A7AF6; Mon, 6 Feb 2006 23:15:07 +0100 (CET) Received: from preston.sources.org (preston [172.19.1.2]) by mail.sources.org (Postfix) with ESMTP id F3AFF11B30; Mon, 6 Feb 2006 23:12:29 +0100 (CET) Received: by preston.sources.org (Postfix, from userid 1000) id BB16BAAE05; Mon, 6 Feb 2006 23:12:29 +0100 (CET) Date: Mon, 6 Feb 2006 23:12:29 +0100 From: Stephane Bortzmeyer To: Jari Urpalainen Message-ID: <20060206221229.GA835@preston.sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: NetBSD 3.0_STABLE sparc64 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at netaktiv.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 X-Mailman-Approved-At: Thu, 09 Feb 2006 03:23:45 -0500 Cc: bortzmeyer@nic.fr, simple@ietf.org Subject: [Simple] draft-xml-patch and pos=append X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org For consistency, I suggest adding a "append" option to the . It is the default, but, IMHO, it should be made explicit, for instance to allow patch authors to clearly state thay they want to append. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 09 03:23:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F775k-0007aE-EC; Thu, 09 Feb 2006 03:23:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Es1-0007gt-Hi for simple@megatron.ietf.org; Mon, 06 Feb 2006 17:30:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13728 for ; Mon, 6 Feb 2006 17:28:25 -0500 (EST) Received: from soyouz2.netaktiv.com ([80.67.170.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6F4I-000774-JW for simple@ietf.org; Mon, 06 Feb 2006 17:42:46 -0500 Received: from localhost (soyouz2 [127.0.0.1]) by soyouz2.netaktiv.com (Postfix) with ESMTP id C9237A7BC5; Mon, 6 Feb 2006 23:29:59 +0100 (CET) Received: from soyouz2.netaktiv.com ([127.0.0.1]) by localhost (soyouz2 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18425-47; Mon, 6 Feb 2006 23:29:58 +0100 (CET) Received: by soyouz2.netaktiv.com (Postfix, from userid 10) id 21FADA7BC3; Mon, 6 Feb 2006 23:29:58 +0100 (CET) Received: from preston.sources.org (preston [172.19.1.2]) by mail.sources.org (Postfix) with ESMTP id DB5A5111B9; Mon, 6 Feb 2006 23:28:07 +0100 (CET) Received: by preston.sources.org (Postfix, from userid 1000) id A4D69AAF28; Mon, 6 Feb 2006 23:28:07 +0100 (CET) Date: Mon, 6 Feb 2006 23:28:07 +0100 From: Stephane Bortzmeyer To: Jari Urpalainen Message-ID: <20060206222807.GA6868@preston.sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: NetBSD 3.0_STABLE sparc64 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at netaktiv.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-Mailman-Approved-At: Thu, 09 Feb 2006 03:23:45 -0500 Cc: bortzmeyer@nic.fr, simple@ietf.org Subject: [Simple] draft-xml-patch and predictible behavior in front of errors X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org AFAIK, it is not specified what to do if one patch raises an error while the previous patches in a were OK. I suggest to add to section 5 "Error Handling" something like: The patches in a element are all applied with success or none is applied. An implementation MUST NOT produce a XML document which results from a partial application of the patches. An implementation MAY continue the patching after an error (to produce diagnostics, for instance), but, since the selectors are applied to the XML document already patched, these diagnostics are of doubtful value. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 09 03:54:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F77Yw-0002cp-1z; Thu, 09 Feb 2006 03:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F77Ys-0002ZZ-58 for simple@megatron.ietf.org; Thu, 09 Feb 2006 03:54:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00323 for ; Thu, 9 Feb 2006 03:52:05 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F77lS-0006jG-Ag for simple@ietf.org; Thu, 09 Feb 2006 04:06:59 -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 k198rJoj022564; Thu, 9 Feb 2006 10:53:22 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Feb 2006 10:53:41 +0200 Received: from mgw-int1.ntc.nokia.com ([172.21.143.96]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 9 Feb 2006 10:53:40 +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 k198ra420049; Thu, 9 Feb 2006 10:53:36 +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 5CE4F93B75; Thu, 9 Feb 2006 10:53:36 +0200 (EET) Subject: Re: [Simple] Re: Other MIME type than xcap-el/attr From: Jari Urpalainen To: ext Jonathan Rosenberg In-Reply-To: <43EA6962.5010004@cisco.com> References: <00de01c62be6$30d9cb50$a0020a0a@samsungk1o0rnf> <43EA6962.5010004@cisco.com> Content-Type: text/plain Date: Thu, 09 Feb 2006 10:53:36 +0200 Message-Id: <1139475216.20654.44.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: 09 Feb 2006 08:53:40.0328 (UTC) FILETIME=[529FCE80:01C62D56] X-Spam-Score: 2.0 (++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Inline -- On Wed, 2006-02-08 at 16:57 -0500, ext Jonathan Rosenberg wrote: > The intent was that its not meant to be extended, and that nothing else > would be used. Do you have a use case or need for something else? > > Thanks, > Jonathan R. > well I had another impression. E.g. with multi-insert one would use multiple elements in the body, would it be the same content-type than xcap-el+xml, for example ? Anyhow, I don't much care if some new content-types are defined by some new extensions, because they don't break the base spec in anyway, imo. That is, you'll negotiate response type with Accept-header and even in some cases you might use request body as well and XCAP capabilities doc may list this extension tag. Although XCAP isn't an XML database or something like that, a really cool extension would be, for example, XQuery like requests over docs. So I don't see a problem for a future extension to define some new semantics with new mime-types (although I don't have an intention to propose something now, no ;-)). Also one could argue that some BNF extensions (which are now explicitly allowed) are useless without the ability to have new mime-types as well. br Jari > Jaekwon Oh wrote: > > > Hello Jonathan and all, > > > > One quick question on XCAP-08. > > Does XCAP allows to extend xcap-el/attr MIME Type for the fragement > > containing element/attrs? > > In other words, does XCAP allows to use other MIME Type than > > xcap-el/attr for the element/attr fragment? > > According to XCAP-08 texts, it seems not allowed; the text says that it > > 'MUST' use such MIME Type. > > Thank you in advance. > > > > BR, > > Jaekwon Oh > > > > Global Stanadards & Research > > Samsung Electronics, Co. Ltd. > > TEL +82 31 279 5086 > > CP +82 16 9530 5086 > > FAX +82 31 279 5130 > > jaekwon.oh@samsung.com > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 09 09:21:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7CfP-0003XH-UQ; Thu, 09 Feb 2006 09:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7CfO-0003WU-TN for simple@megatron.ietf.org; Thu, 09 Feb 2006 09:21:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25124 for ; Thu, 9 Feb 2006 09:19:10 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7Cs1-0001Au-Uk for simple@ietf.org; Thu, 09 Feb 2006 09:34:07 -0500 Received: from [10.10.2.124] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k19EKhXH012282 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 9 Feb 2006 08:20:45 -0600 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Simple WG From: Dean Willis Date: Thu, 9 Feb 2006 08:20:59 -0600 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [Simple] OMA and draft-niemi-simple-chat-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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org OMA's messaging working group is all abuzz about their alleged need for draft-niemi-simple-chat-03.txt to become an RFC. I'm trying to figure exactly which part of this draft they think they need, and I'll get back with you when I have more information. So far, they've told me that their entire chat room approach is built around this draft. I presume they're using the MSRP extension in this draft, but don't know for sure. However, it may be time to give this draft another read, and see what we think about the problem set it's trying to solve -- N-way centralized MSRP conferencing with sidebars. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 09 10:32:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Dmt-0003fP-Or; Thu, 09 Feb 2006 10:32:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Dms-0003eg-5B for simple@megatron.ietf.org; Thu, 09 Feb 2006 10:32:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01237 for ; Thu, 9 Feb 2006 10:30:59 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7DzY-0003n5-5j for simple@ietf.org; Thu, 09 Feb 2006 10:45:57 -0500 Received: from [10.10.2.124] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k19FWXik012915 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 9 Feb 2006 09:32:36 -0600 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: Dean Willis Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt Date: Thu, 9 Feb 2006 09:32:51 -0600 To: Simple WG X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Feb 9, 2006, at 8:20 AM, Dean Willis wrote: > > OMA's messaging working group is all abuzz about their alleged need > for draft-niemi-simple-chat-03.txt to become an RFC. > > I'm trying to figure exactly which part of this draft they think > they need, and I'll get back with you when I have more information. > So far, they've told me that their entire chat room approach is > built around this draft. I presume they're using the MSRP extension > in this draft, but don't know for sure. > > However, it may be time to give this draft another read, and see > what we think about the problem set it's trying to solve -- N-way > centralized MSRP conferencing with sidebars. > For the google-challenged: http://www.watersprings.org/pub/id/draft-niemi-simple-chat-03.txt -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 09 12:00:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7F9p-0001Id-Rv; Thu, 09 Feb 2006 12:00:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7F9c-0001CL-Ay for simple@megatron.ietf.org; Thu, 09 Feb 2006 12:00:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08618 for ; Thu, 9 Feb 2006 11:58:35 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7FMD-00077s-1x for simple@ietf.org; Thu, 09 Feb 2006 12:13:34 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 7F8ED194492 for ; Thu, 9 Feb 2006 17:59:52 +0100 (CET) Received: from [192.168.1.63] ([192.168.1.63]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Feb 2006 17:58:27 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <01501f659b97978105eadf8007f90d72@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt Date: Thu, 9 Feb 2006 18:00:05 +0100 To: Dean Willis X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 09 Feb 2006 16:58:27.0593 (UTC) FILETIME=[0BFC3790:01C62D9A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This draft is not mature at all and I hope OMA don't force SIMPLE to stick to whatever is in there just because that's how they defined their service to be (some of us have the opinion that whatever is in there now is broken and does not work with MSRP properly). Thanks, Hisham On Feb 9, 2006, at 3:20 PM, Dean Willis wrote: > > OMA's messaging working group is all abuzz about their alleged need > for draft-niemi-simple-chat-03.txt to become an RFC. > > I'm trying to figure exactly which part of this draft they think they > need, and I'll get back with you when I have more information. So far, > they've told me that their entire chat room approach is built around > this draft. I presume they're using the MSRP extension in this draft, > but don't know for sure. > > However, it may be time to give this draft another read, and see what > we think about the problem set it's trying to solve -- N-way > centralized MSRP conferencing with sidebars. > > -- > Dean > > > _______________________________________________ > 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 Feb 09 13:04:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7G9f-000796-JN; Thu, 09 Feb 2006 13:04:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7G9d-00078K-JA for simple@megatron.ietf.org; Thu, 09 Feb 2006 13:04:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14498 for ; Thu, 9 Feb 2006 13:02:35 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7GMJ-0001DB-0a for simple@ietf.org; Thu, 09 Feb 2006 13:17:36 -0500 Received: from [10.10.2.124] (expo112.palais-congres-paris.fr [212.155.202.112] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k19I4EOv013803 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 9 Feb 2006 12:04:16 -0600 In-Reply-To: <01501f659b97978105eadf8007f90d72@telio.no> References: <01501f659b97978105eadf8007f90d72@telio.no> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B95B7B7-7348-468F-8BBA-292B01AD9DB5@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt Date: Thu, 9 Feb 2006 12:04:31 -0600 To: Hisham Khartabil X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I just had a chat with some of the OMA messaging people, and the main thing they're dealing with is sidebar conversations in MSRP conferences. They also want dynamic alias negotiation. They'll send some requirements docs and supporting material to the list in the next few days. It would be nice to find a path towards a solution that works for everybody involved. -- Dean Willis IETF liaison to OMA. On Feb 9, 2006, at 11:00 AM, Hisham Khartabil wrote: > This draft is not mature at all and I hope OMA don't force SIMPLE > to stick to whatever is in there just because that's how they > defined their service to be (some of us have the opinion that > whatever is in there now is broken and does not work with MSRP > properly). > > Thanks, > Hisham > > On Feb 9, 2006, at 3:20 PM, Dean Willis wrote: > >> >> OMA's messaging working group is all abuzz about their alleged >> need for draft-niemi-simple-chat-03.txt to become an RFC. >> >> I'm trying to figure exactly which part of this draft they think >> they need, and I'll get back with you when I have more >> information. So far, they've told me that their entire chat room >> approach is built around this draft. I presume they're using the >> MSRP extension in this draft, but don't know for sure. >> >> However, it may be time to give this draft another read, and see >> what we think about the problem set it's trying to solve -- N-way >> centralized MSRP conferencing with sidebars. >> >> -- >> Dean >> >> >> _______________________________________________ >> 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 Feb 09 13:21:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7GPx-0000a1-Gj; Thu, 09 Feb 2006 13:21:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7GPv-0000Sl-4k for simple@megatron.ietf.org; Thu, 09 Feb 2006 13:21:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17661 for ; Thu, 9 Feb 2006 13:19:19 -0500 (EST) Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7GcQ-00020h-Fn for simple@ietf.org; Thu, 09 Feb 2006 13:34:17 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k19IKXB01186; Thu, 9 Feb 2006 13:20:33 -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] OMA and draft-niemi-simple-chat-03.txt Date: Thu, 9 Feb 2006 12:20:33 -0600 Message-ID: Thread-Topic: [Simple] OMA and draft-niemi-simple-chat-03.txt Thread-Index: AcYtpCsiN9AzcqQ/Sii8LpGJft8zJwAAIfmg From: "Mary Barnes" To: "Dean Willis" , "Hisham Khartabil" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org When this draft was discussed previously, the discussion was that the aliasing (nickname) problem was a more general SIP problem and it was proposed that a team be assembled to address that general problem. I'm assuming that team never formed or if they did are there any conclusions to share?=20 And, I thought the sidebar functionality was suggested to be supported by the work in XCON.=20 I'm in agreement with Hisham in that I'd rather not see a specialized solution for OMA pushed through when general solutions are more appropriate.=20 Mary. -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Dean Willis Sent: Thursday, February 09, 2006 12:05 PM To: Hisham Khartabil Cc: Simple WG Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt I just had a chat with some of the OMA messaging people, and the main =20 thing they're dealing with is sidebar conversations in MSRP =20 conferences. They also want dynamic alias negotiation. They'll send =20 some requirements docs and supporting material to the list in the =20 next few days. It would be nice to find a path towards a solution that works for =20 everybody involved. -- Dean Willis IETF liaison to OMA. On Feb 9, 2006, at 11:00 AM, Hisham Khartabil wrote: > This draft is not mature at all and I hope OMA don't force SIMPLE =20 > to stick to whatever is in there just because that's how they =20 > defined their service to be (some of us have the opinion that =20 > whatever is in there now is broken and does not work with MSRP =20 > properly). > > Thanks, > Hisham > > On Feb 9, 2006, at 3:20 PM, Dean Willis wrote: > >> >> OMA's messaging working group is all abuzz about their alleged =20 >> need for draft-niemi-simple-chat-03.txt to become an RFC. >> >> I'm trying to figure exactly which part of this draft they think =20 >> they need, and I'll get back with you when I have more =20 >> information. So far, they've told me that their entire chat room =20 >> approach is built around this draft. I presume they're using the =20 >> MSRP extension in this draft, but don't know for sure. >> >> However, it may be time to give this draft another read, and see =20 >> what we think about the problem set it's trying to solve -- N-way =20 >> centralized MSRP conferencing with sidebars. >> >> -- >> Dean >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 09 13:55:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Gwj-0006sk-JF; Thu, 09 Feb 2006 13:55:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Gwf-0006rA-Hj for simple@megatron.ietf.org; Thu, 09 Feb 2006 13:55:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20642 for ; Thu, 9 Feb 2006 13:53:19 -0500 (EST) 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 1F7H9N-0003Bm-AJ for simple@ietf.org; Thu, 09 Feb 2006 14:08:18 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 09 Feb 2006 10:54:49 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k19Isjk3018915; Thu, 9 Feb 2006 10:54:48 -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 Feb 2006 13:54:47 -0500 Received: from [161.44.79.51] ([161.44.79.51]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 13:54:47 -0500 Message-ID: <43EB8FF6.9050200@cisco.com> Date: Thu, 09 Feb 2006 13:54:46 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mary Barnes Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2006 18:54:47.0236 (UTC) FILETIME=[4C2D3840:01C62DAA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Cc: Simple WG , Dean Willis X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I'm in violent agreement with Mary and Hisham. There are a number of things that concern me: - the balkanization of media, in that certain features that ought to be media independent are instead implemented in a unique way for this one medium. - I never liked distsend, for the reason above - it is an end run around sidebars. But in addition to that it has been recently pointed out on the list that it can't work, because only SEND is chunked in MSRP. - as Mary mentions, nicknames aren't just an IM issue. (Balkanization again.) And getting the semantics of nicknames right may be tricky. (Within a particular context (greater than a single conference session) I don't want the same nickname to be grabbed by different people too easily.) Paul Mary Barnes wrote: > When this draft was discussed previously, the discussion was that the > aliasing (nickname) problem was a more general SIP problem and it was > proposed that a team be assembled to address that general problem. I'm > assuming that team never formed or if they did are there any conclusions > to share? > > And, I thought the sidebar functionality was suggested to be supported > by the work in XCON. > > I'm in agreement with Hisham in that I'd rather not see a specialized > solution for OMA pushed through when general solutions are more > appropriate. > > Mary. > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Dean Willis > Sent: Thursday, February 09, 2006 12:05 PM > To: Hisham Khartabil > Cc: Simple WG > Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt > > > > I just had a chat with some of the OMA messaging people, and the main > thing they're dealing with is sidebar conversations in MSRP > conferences. They also want dynamic alias negotiation. They'll send > some requirements docs and supporting material to the list in the > next few days. > > It would be nice to find a path towards a solution that works for > everybody involved. > > -- > Dean Willis > IETF liaison to OMA. > > On Feb 9, 2006, at 11:00 AM, Hisham Khartabil wrote: > > >>This draft is not mature at all and I hope OMA don't force SIMPLE >>to stick to whatever is in there just because that's how they >>defined their service to be (some of us have the opinion that >>whatever is in there now is broken and does not work with MSRP >>properly). >> >>Thanks, >>Hisham >> >>On Feb 9, 2006, at 3:20 PM, Dean Willis wrote: >> >> >>>OMA's messaging working group is all abuzz about their alleged >>>need for draft-niemi-simple-chat-03.txt to become an RFC. >>> >>>I'm trying to figure exactly which part of this draft they think >>>they need, and I'll get back with you when I have more >>>information. So far, they've told me that their entire chat room >>>approach is built around this draft. I presume they're using the >>>MSRP extension in this draft, but don't know for sure. >>> >>>However, it may be time to give this draft another read, and see >>>what we think about the problem set it's trying to solve -- N-way >>>centralized MSRP conferencing with sidebars. >>> >>>-- >>>Dean >>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 10 02:30:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Sjk-0003xd-Vo; Fri, 10 Feb 2006 02:30:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Sjj-0003uI-52 for simple@megatron.ietf.org; Fri, 10 Feb 2006 02:30:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23280 for ; Fri, 10 Feb 2006 02:28:52 -0500 (EST) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7Swe-0005g2-Nv for simple@ietf.org; Fri, 10 Feb 2006 02:43: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 k1A7UR0W018830; Fri, 10 Feb 2006 09:30:28 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2006 09:30:27 +0200 Received: from [172.21.36.206] ([172.21.36.206]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Feb 2006 09:30:26 +0200 Message-ID: <43EC4111.7020706@nokia.com> Date: Fri, 10 Feb 2006 09:30:25 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Hisham Khartabil Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt References: <01501f659b97978105eadf8007f90d72@telio.no> In-Reply-To: <01501f659b97978105eadf8007f90d72@telio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2006 07:30:26.0521 (UTC) FILETIME=[DC7F1490:01C62E13] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Simple WG , Dean Willis X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext Hisham Khartabil wrote: > This draft is not mature at all and I hope OMA don't force SIMPLE to > stick to whatever is in there just because that's how they defined their > service to be (some of us have the opinion that whatever is in there now > is broken and does not work with MSRP properly). Really? Care to point out exactly where things are broken and how we should fix them? You know, things don't really improve if all you do is bitch about drafts by yourselves. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 10 02:32:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Slq-0005Y2-PH; Fri, 10 Feb 2006 02:32:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Slm-0005XK-Dq for simple@megatron.ietf.org; Fri, 10 Feb 2006 02:32:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23446 for ; Fri, 10 Feb 2006 02:30:51 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7Sya-0005kP-JP for simple@ietf.org; Fri, 10 Feb 2006 02:45:58 -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 k1A7W15i026283; Fri, 10 Feb 2006 09:32:08 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2006 09:32:27 +0200 Received: from [172.21.36.206] ([172.21.36.206]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Feb 2006 09:32:27 +0200 Message-ID: <43EC418A.2000100@nokia.com> Date: Fri, 10 Feb 2006 09:32:26 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Mary Barnes Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2006 07:32:27.0278 (UTC) FILETIME=[247922E0:01C62E14] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: Simple WG , Dean Willis X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext Mary Barnes wrote: > I'm in agreement with Hisham in that I'd rather not see a specialized > solution for OMA pushed through when general solutions are more > appropriate. We'll be more than happy to incorporate the generalized sidebar functionality in; is there an I-D I can reference here? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 10 02:43:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Swh-0001BK-Mn; Fri, 10 Feb 2006 02:43:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Swf-0001AB-TO for simple@megatron.ietf.org; Fri, 10 Feb 2006 02:43:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24821 for ; Fri, 10 Feb 2006 02:42:13 -0500 (EST) Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7T9a-0006Al-VC for simple@ietf.org; Fri, 10 Feb 2006 02:57:19 -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 k1A7ho7Z032592; Fri, 10 Feb 2006 09:43:51 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2006 09:43:09 +0200 Received: from [172.21.36.206] ([172.21.36.206]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Feb 2006 09:43:09 +0200 Message-ID: <43EC440C.4070802@nokia.com> Date: Fri, 10 Feb 2006 09:43:08 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Paul Kyzivat Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt References: <43EB8FF6.9050200@cisco.com> In-Reply-To: <43EB8FF6.9050200@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2006 07:43:09.0469 (UTC) FILETIME=[A33FB4D0:01C62E15] X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit Cc: Dean Willis , Mary Barnes , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Paul, I'm not half as concerned about this balkanization of conferencing features as you appear to be. In fact, I think what you describe is only a problem if we look at things with the standards-committee glasses on. Of course then, everything even remotely resembling conferencing needs to be dumped to XCON, which we are now eagerly waiting to get their act together so we can make forward progress. Why I think MSRP chat is important and needs to get done *now* is that without multi-user chat, MSRP will pale in comparison to every other chat out there. Check out IRC or Jabber MUC. They both have nicknames, private messages (!=sidebar) and sidebars. Done in chat-specific way. I happen to believe we can make these features in a chat specific way in MSRP and whenever XCON gets the generic mechanisms ready, we can migrate to them. So where's the problem? Cheers, Aki ext Paul Kyzivat wrote: > I'm in violent agreement with Mary and Hisham. > > There are a number of things that concern me: > > - the balkanization of media, in that certain features that > ought to be media independent are instead implemented in > a unique way for this one medium. > > - I never liked distsend, for the reason above - it is an > end run around sidebars. But in addition to that it has > been recently pointed out on the list that it can't work, > because only SEND is chunked in MSRP. > > - as Mary mentions, nicknames aren't just an IM issue. > (Balkanization again.) And getting the semantics of > nicknames right may be tricky. (Within a particular > context (greater than a single conference session) > I don't want the same nickname to be grabbed by > different people too easily.) > > Paul > > Mary Barnes wrote: > >> When this draft was discussed previously, the discussion was that the >> aliasing (nickname) problem was a more general SIP problem and it was >> proposed that a team be assembled to address that general problem. I'm >> assuming that team never formed or if they did are there any conclusions >> to share? >> And, I thought the sidebar functionality was suggested to be supported >> by the work in XCON. >> I'm in agreement with Hisham in that I'd rather not see a specialized >> solution for OMA pushed through when general solutions are more >> appropriate. >> Mary. >> >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf >> Of Dean Willis >> Sent: Thursday, February 09, 2006 12:05 PM >> To: Hisham Khartabil >> Cc: Simple WG >> Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt >> >> >> >> I just had a chat with some of the OMA messaging people, and the main >> thing they're dealing with is sidebar conversations in MSRP >> conferences. They also want dynamic alias negotiation. They'll send >> some requirements docs and supporting material to the list in the >> next few days. >> >> It would be nice to find a path towards a solution that works for >> everybody involved. >> >> -- >> Dean Willis >> IETF liaison to OMA. >> >> On Feb 9, 2006, at 11:00 AM, Hisham Khartabil wrote: >> >> >>> This draft is not mature at all and I hope OMA don't force SIMPLE to >>> stick to whatever is in there just because that's how they defined >>> their service to be (some of us have the opinion that whatever is in >>> there now is broken and does not work with MSRP properly). >>> >>> Thanks, >>> Hisham >>> >>> On Feb 9, 2006, at 3:20 PM, Dean Willis wrote: >>> >>> >>>> OMA's messaging working group is all abuzz about their alleged need >>>> for draft-niemi-simple-chat-03.txt to become an RFC. >>>> >>>> I'm trying to figure exactly which part of this draft they think >>>> they need, and I'll get back with you when I have more information. >>>> So far, they've told me that their entire chat room approach is >>>> built around this draft. I presume they're using the MSRP extension >>>> in this draft, but don't know for sure. >>>> >>>> However, it may be time to give this draft another read, and see >>>> what we think about the problem set it's trying to solve -- N-way >>>> centralized MSRP conferencing with sidebars. >>>> >>>> -- >>>> Dean >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > 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 Feb 10 03:05:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7THb-0001eO-8T; Fri, 10 Feb 2006 03:05:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7THZ-0001dH-LB for simple@megatron.ietf.org; Fri, 10 Feb 2006 03:05:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27284 for ; Fri, 10 Feb 2006 03:03:40 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7TUK-00076R-2U for simple@ietf.org; Fri, 10 Feb 2006 03:18:47 -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 k1A84xS9015162; Fri, 10 Feb 2006 10:05:03 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2006 10:04:11 +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, 10 Feb 2006 10:04:11 +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 k1A849414741; Fri, 10 Feb 2006 10:04:09 +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 78B5493B76; Fri, 10 Feb 2006 10:04:09 +0200 (EET) From: Jari Urpalainen To: ext ext Stephane Bortzmeyer In-Reply-To: <20060209160719.GA21998@nic.fr> References: <20060206220115.GA201@preston.sources.org> <43E9F8A5.6030805@nokia.com> <20060209160719.GA21998@nic.fr> Content-Type: text/plain Date: Fri, 10 Feb 2006 10:04:09 +0200 Message-Id: <1139558649.29343.13.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 Feb 2006 08:04:11.0086 (UTC) FILETIME=[933B2EE0:01C62E18] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: [Simple] Re: draft-xml-patch and pos=append X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Thu, 2006-02-09 at 17:07 +0100, ext ext Stephane Bortzmeyer wrote: > On Wed, Feb 08, 2006 at 03:56:53PM +0200, > Jari Urpalainen wrote > a message of 112 lines which said: > > > >For consistency, I suggest adding a "append" option to the > > >. It is the default, but, IMHO, it > > >should be made explicit, for instance to allow patch authors to > > >clearly state thay they want to append. > > > > > Well, I had this psvi like feature in the previous version, but this > > is indeed a bad habit, one of those things that come from the w3c > > schema language. > > Could you elaborate? I absolutely do not see the connection with the > idiosyncrasies of the W3C Schema language. > > I was not suggesting to use the PSVI. I did not suggest to mess with > the infoset. I suggested to add the "append" option and to let the > application do the same thing for pos="append" and for no pos. Sorry, my comment was badly phrased. With a reference to psvi I meant extra processing, using default values for attributes is discouraged in rfc3470 (the previous one had a default value "to", which meant append rule for text, element, pi and comment, so "to" was also used with attributes & namespaces). Having two possibilities for the same thing is imo a bad thing. In this particular case, it just increases the "body" size, i.e. the diff should be as small as possible, and also it adds an unnecessary condition check for implementations. So it is additional "noise" that is discouraged simply by disallowing it. Implementations have to be careful in many other things as well before having a working implementation. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 10 03:50:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7TzS-0000tf-Qi; Fri, 10 Feb 2006 03:50:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7TzN-0000si-5a for simple@megatron.ietf.org; Fri, 10 Feb 2006 03:50:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29625 for ; Fri, 10 Feb 2006 03:48:56 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7UCA-0008SO-Pe for simple@ietf.org; Fri, 10 Feb 2006 04:04:03 -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 k1A8oASe013247; Fri, 10 Feb 2006 10:50:11 +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 Feb 2006 10:49:44 +0200 Received: from [127.0.0.1] ([172.21.38.244]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Feb 2006 10:49:43 +0200 Message-ID: <43EC53A7.9030109@nokia.com> Date: Fri, 10 Feb 2006 10:49:43 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt References: <43EB8FF6.9050200@cisco.com> <43EC440C.4070802@nokia.com> In-Reply-To: <43EC440C.4070802@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2006 08:49:43.0913 (UTC) FILETIME=[F01F7D90:01C62E1E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , Simple WG , Mary Barnes , Dean Willis X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I want to stress Aki's point here. Existing proprietary systems all offer multiuser chat type of functions. Other standards, namely jabber, offer also the same function. I can't understand why are we neglecting MSRP the well-deserved chat functionality. Or is the a plan to make MSRP a looser? /Miguel Aki Niemi wrote: > Paul, > > I'm not half as concerned about this balkanization of conferencing > features as you appear to be. In fact, I think what you describe is only > a problem if we look at things with the standards-committee glasses on. > Of course then, everything even remotely resembling conferencing needs > to be dumped to XCON, which we are now eagerly waiting to get their act > together so we can make forward progress. > > Why I think MSRP chat is important and needs to get done *now* is that > without multi-user chat, MSRP will pale in comparison to every other > chat out there. Check out IRC or Jabber MUC. They both have nicknames, > private messages (!=sidebar) and sidebars. Done in chat-specific way. > > I happen to believe we can make these features in a chat specific way in > MSRP and whenever XCON gets the generic mechanisms ready, we can migrate > to them. So where's the problem? > > Cheers, > Aki > > ext Paul Kyzivat wrote: >> I'm in violent agreement with Mary and Hisham. >> >> There are a number of things that concern me: >> >> - the balkanization of media, in that certain features that >> ought to be media independent are instead implemented in >> a unique way for this one medium. >> >> - I never liked distsend, for the reason above - it is an >> end run around sidebars. But in addition to that it has >> been recently pointed out on the list that it can't work, >> because only SEND is chunked in MSRP. >> >> - as Mary mentions, nicknames aren't just an IM issue. >> (Balkanization again.) And getting the semantics of >> nicknames right may be tricky. (Within a particular >> context (greater than a single conference session) >> I don't want the same nickname to be grabbed by >> different people too easily.) >> >> Paul >> >> Mary Barnes wrote: >> >>> When this draft was discussed previously, the discussion was that the >>> aliasing (nickname) problem was a more general SIP problem and it was >>> proposed that a team be assembled to address that general problem. I'm >>> assuming that team never formed or if they did are there any conclusions >>> to share? >>> And, I thought the sidebar functionality was suggested to be supported >>> by the work in XCON. >>> I'm in agreement with Hisham in that I'd rather not see a specialized >>> solution for OMA pushed through when general solutions are more >>> appropriate. >>> Mary. >>> >>> -----Original Message----- >>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf >>> Of Dean Willis >>> Sent: Thursday, February 09, 2006 12:05 PM >>> To: Hisham Khartabil >>> Cc: Simple WG >>> Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt >>> >>> >>> >>> I just had a chat with some of the OMA messaging people, and the >>> main thing they're dealing with is sidebar conversations in MSRP >>> conferences. They also want dynamic alias negotiation. They'll send >>> some requirements docs and supporting material to the list in the >>> next few days. >>> >>> It would be nice to find a path towards a solution that works for >>> everybody involved. >>> >>> -- >>> Dean Willis >>> IETF liaison to OMA. >>> >>> On Feb 9, 2006, at 11:00 AM, Hisham Khartabil wrote: >>> >>> >>>> This draft is not mature at all and I hope OMA don't force SIMPLE >>>> to stick to whatever is in there just because that's how they >>>> defined their service to be (some of us have the opinion that >>>> whatever is in there now is broken and does not work with MSRP >>>> properly). >>>> >>>> Thanks, >>>> Hisham >>>> >>>> On Feb 9, 2006, at 3:20 PM, Dean Willis wrote: >>>> >>>> >>>>> OMA's messaging working group is all abuzz about their alleged >>>>> need for draft-niemi-simple-chat-03.txt to become an RFC. >>>>> >>>>> I'm trying to figure exactly which part of this draft they think >>>>> they need, and I'll get back with you when I have more >>>>> information. So far, they've told me that their entire chat room >>>>> approach is built around this draft. I presume they're using the >>>>> MSRP extension in this draft, but don't know for sure. >>>>> >>>>> However, it may be time to give this draft another read, and see >>>>> what we think about the problem set it's trying to solve -- N-way >>>>> centralized MSRP conferencing with sidebars. >>>>> >>>>> -- >>>>> Dean >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> _______________________________________________ >> 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 > -- 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 Fri Feb 10 03:58:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7U6k-0003DQ-9Q; Fri, 10 Feb 2006 03:58:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7U6i-0003CQ-Fs for simple@megatron.ietf.org; Fri, 10 Feb 2006 03:58:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00132 for ; Fri, 10 Feb 2006 03:56:33 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7UJX-0000HI-GW for simple@ietf.org; Fri, 10 Feb 2006 04:11:41 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 8CAEB19448A for ; Fri, 10 Feb 2006 09:58:04 +0100 (CET) Received: from [192.168.1.69] ([192.168.1.69]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2006 09:56:43 +0100 In-Reply-To: <43EC4111.7020706@nokia.com> References: <01501f659b97978105eadf8007f90d72@telio.no> <43EC4111.7020706@nokia.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 Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt Date: Fri, 10 Feb 2006 09:58:18 +0100 To: Aki Niemi X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 10 Feb 2006 08:56:43.0728 (UTC) FILETIME=[EA5A2D00:01C62E1F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Simple WG , Dean Willis X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Feb 10, 2006, at 8:30 AM, Aki Niemi wrote: > > ext Hisham Khartabil wrote: >> This draft is not mature at all and I hope OMA don't force SIMPLE to >> stick to whatever is in there just because that's how they defined >> their service to be (some of us have the opinion that whatever is in >> there now is broken and does not work with MSRP properly). > > Really? Care to point out exactly where things are broken and how we > should fix them? You cannot claim that the draft is mature and has the group consensus. This is the warning that I was sending out. I was acting as a chair and was not specifically pointing to any technical problems. People that have technical problems with the draft have already begun to bring those issues up as a reaction to my email. > > You know, things don't really improve if all you do is bitch about > drafts by yourselves. This is a public forum and I would appreciate some respect to others on it. There were no issues about this draft discussed privately "by ourselves". The objections to the technical solution was either discussed on the mailing list, in an IETF meeting or to the authors. Hisham > > Cheers, > Aki > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 10 04:08:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7UGE-0007QB-Mw; Fri, 10 Feb 2006 04:08:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7UGC-0007Pz-Qb for simple@megatron.ietf.org; Fri, 10 Feb 2006 04:08:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00821 for ; Fri, 10 Feb 2006 04:06:29 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7UTA-0000b1-NE for simple@ietf.org; Fri, 10 Feb 2006 04:21: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 EE2E419448A for ; Fri, 10 Feb 2006 10:08:02 +0100 (CET) Received: from [192.168.1.69] ([192.168.1.69]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2006 10:06:41 +0100 In-Reply-To: <43EC53A7.9030109@nokia.com> References: <43EB8FF6.9050200@cisco.com> <43EC440C.4070802@nokia.com> <43EC53A7.9030109@nokia.com> 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] OMA and draft-niemi-simple-chat-03.txt Date: Fri, 10 Feb 2006 10:08:15 +0100 To: Miguel Garcia X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 10 Feb 2006 09:06:41.0822 (UTC) FILETIME=[4ED813E0:01C62E21] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: 7bit Cc: Mary Barnes , Paul Kyzivat , Aki Niemi , Simple WG , Dean Willis X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org No one is denying MSRP the chat functionality. People want it and need it. But there is nothing wrong with arguing the technical solution at hand. I agree with you that we need a solution *now*, and no one can argue against the fact that XCON has been slow in producing results. My objection to the draft is the LISTSEND method. Can you remind folks why a solution similar to http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-list- message-06.txt is not acceptable? Hisham On Feb 10, 2006, at 9:49 AM, Miguel Garcia wrote: > I want to stress Aki's point here. Existing proprietary systems all > offer multiuser chat type of functions. Other standards, namely > jabber, offer also the same function. I can't understand why are we > neglecting MSRP the well-deserved chat functionality. Or is the a plan > to make MSRP a looser? > > /Miguel > > > Aki Niemi wrote: >> Paul, >> I'm not half as concerned about this balkanization of conferencing >> features as you appear to be. In fact, I think what you describe is >> only a problem if we look at things with the standards-committee >> glasses on. Of course then, everything even remotely resembling >> conferencing needs to be dumped to XCON, which we are now eagerly >> waiting to get their act together so we can make forward progress. >> Why I think MSRP chat is important and needs to get done *now* is >> that without multi-user chat, MSRP will pale in comparison to every >> other chat out there. Check out IRC or Jabber MUC. They both have >> nicknames, private messages (!=sidebar) and sidebars. Done in >> chat-specific way. >> I happen to believe we can make these features in a chat specific way >> in MSRP and whenever XCON gets the generic mechanisms ready, we can >> migrate to them. So where's the problem? >> Cheers, >> Aki >> ext Paul Kyzivat wrote: >>> I'm in violent agreement with Mary and Hisham. >>> >>> There are a number of things that concern me: >>> >>> - the balkanization of media, in that certain features that >>> ought to be media independent are instead implemented in >>> a unique way for this one medium. >>> >>> - I never liked distsend, for the reason above - it is an >>> end run around sidebars. But in addition to that it has >>> been recently pointed out on the list that it can't work, >>> because only SEND is chunked in MSRP. >>> >>> - as Mary mentions, nicknames aren't just an IM issue. >>> (Balkanization again.) And getting the semantics of >>> nicknames right may be tricky. (Within a particular >>> context (greater than a single conference session) >>> I don't want the same nickname to be grabbed by >>> different people too easily.) >>> >>> Paul >>> >>> Mary Barnes wrote: >>> >>>> When this draft was discussed previously, the discussion was that >>>> the >>>> aliasing (nickname) problem was a more general SIP problem and it >>>> was >>>> proposed that a team be assembled to address that general problem. >>>> I'm >>>> assuming that team never formed or if they did are there any >>>> conclusions >>>> to share? >>>> And, I thought the sidebar functionality was suggested to be >>>> supported >>>> by the work in XCON. >>>> I'm in agreement with Hisham in that I'd rather not see a >>>> specialized >>>> solution for OMA pushed through when general solutions are more >>>> appropriate. >>>> Mary. >>>> >>>> -----Original Message----- >>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>>> Behalf >>>> Of Dean Willis >>>> Sent: Thursday, February 09, 2006 12:05 PM >>>> To: Hisham Khartabil >>>> Cc: Simple WG >>>> Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt >>>> >>>> >>>> >>>> I just had a chat with some of the OMA messaging people, and the >>>> main thing they're dealing with is sidebar conversations in MSRP >>>> conferences. They also want dynamic alias negotiation. They'll send >>>> some requirements docs and supporting material to the list in the >>>> next few days. >>>> >>>> It would be nice to find a path towards a solution that works for >>>> everybody involved. >>>> >>>> -- >>>> Dean Willis >>>> IETF liaison to OMA. >>>> >>>> On Feb 9, 2006, at 11:00 AM, Hisham Khartabil wrote: >>>> >>>> >>>>> This draft is not mature at all and I hope OMA don't force SIMPLE >>>>> to stick to whatever is in there just because that's how they >>>>> defined their service to be (some of us have the opinion that >>>>> whatever is in there now is broken and does not work with MSRP >>>>> properly). >>>>> >>>>> Thanks, >>>>> Hisham >>>>> >>>>> On Feb 9, 2006, at 3:20 PM, Dean Willis wrote: >>>>> >>>>> >>>>>> OMA's messaging working group is all abuzz about their alleged >>>>>> need for draft-niemi-simple-chat-03.txt to become an RFC. >>>>>> >>>>>> I'm trying to figure exactly which part of this draft they think >>>>>> they need, and I'll get back with you when I have more >>>>>> information. So far, they've told me that their entire chat room >>>>>> approach is built around this draft. I presume they're using the >>>>>> MSRP extension in this draft, but don't know for sure. >>>>>> >>>>>> However, it may be time to give this draft another read, and see >>>>>> what we think about the problem set it's trying to solve -- N-way >>>>>> centralized MSRP conferencing with sidebars. >>>>>> >>>>>> -- >>>>>> Dean >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >>> _______________________________________________ >>> 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 > > -- > 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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 10 04:11:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7UJn-0008FV-3V; Fri, 10 Feb 2006 04:11:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7UJm-0008Ev-3M for simple@megatron.ietf.org; Fri, 10 Feb 2006 04:11:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01087 for ; Fri, 10 Feb 2006 04:10:06 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7UWe-0000jN-H1 for simple@ietf.org; Fri, 10 Feb 2006 04:25:14 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1A9BVp9015390; Fri, 10 Feb 2006 11:11:32 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2006 11:11:38 +0200 Received: from [172.21.36.206] ([172.21.36.206]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Feb 2006 11:11:38 +0200 Message-ID: <43EC58C9.8030805@nokia.com> Date: Fri, 10 Feb 2006 11:11:37 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Hisham Khartabil Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt References: <01501f659b97978105eadf8007f90d72@telio.no> <43EC4111.7020706@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2006 09:11:38.0311 (UTC) FILETIME=[FF90B570:01C62E21] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Simple WG , Dean Willis X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext Hisham Khartabil wrote: >>> This draft is not mature at all and I hope OMA don't force SIMPLE to >>> stick to whatever is in there just because that's how they defined >>> their service to be (some of us have the opinion that whatever is in >>> there now is broken and does not work with MSRP properly). >> >> >> Really? Care to point out exactly where things are broken and how we >> should fix them? > > > You cannot claim that the draft is mature and has the group consensus. I have never claimed anything like that. It is not mature and definitely hasn't got group consensus. I would like to get it there sooner rahter than later, because I happen to think this is important. > This is the warning that I was sending out. I was acting as a chair and > was not specifically pointing to any technical problems. Exactly, you were stating a general comment that the content of the draft is broken and won't work with MSRP. I'd much rather see specific comments to technical issues because those we can fix. > People that > have technical problems with the draft have already begun to bring those > issues up as a reaction to my email. The one technical issue I've seen raised was about using non-SEND method for sending private messages. That will be fixed in the next version we're working on right now. >> You know, things don't really improve if all you do is bitch about >> drafts by yourselves. > > > This is a public forum and I would appreciate some respect to others on > it. There were no issues about this draft discussed privately "by > ourselves". The objections to the technical solution was either > discussed on the mailing list, in an IETF meeting or to the authors. Good, then I misinterpreted your comment about "some of us have the opinion". Sorry about that. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 10 04:17:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7UP0-0003iy-Qi; Fri, 10 Feb 2006 04:17:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7UOy-0003eR-7s for simple@megatron.ietf.org; Fri, 10 Feb 2006 04:17:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01711 for ; Fri, 10 Feb 2006 04:15:33 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7Ubs-0000yf-Ln for simple@ietf.org; Fri, 10 Feb 2006 04:30:38 -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 k1A9GguM010840; Fri, 10 Feb 2006 11:16:44 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2006 11:16:59 +0200 Received: from [127.0.0.1] ([172.21.38.244]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Feb 2006 11:16:58 +0200 Message-ID: <43EC5A0A.5020108@nokia.com> Date: Fri, 10 Feb 2006 11:16:58 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt References: <43EB8FF6.9050200@cisco.com> <43EC440C.4070802@nokia.com> <43EC53A7.9030109@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2006 09:16:58.0607 (UTC) FILETIME=[BE79FFF0:01C62E22] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Mary Barnes , Paul Kyzivat , Aki Niemi , Simple WG , Dean Willis X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hisham Khartabil wrote: > > Can you remind folks why a solution similar to > http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-list-message-06.txt > is not acceptable? > In fact it is. Our current working copy (that we are struggling to finalize), is not using a new MSRP method for distribution of messages (uses the SEND method). It also uses the To, Cc, and Bcc headers in the Message/CPIM wrapper to indicate the distribution list. /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 Fri Feb 10 05:09:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7VDa-0006Fu-8t; Fri, 10 Feb 2006 05:09:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7VDY-0006EW-Pb for simple@megatron.ietf.org; Fri, 10 Feb 2006 05:09:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05238 for ; Fri, 10 Feb 2006 05:07:49 -0500 (EST) From: Silvestr.Peknik@tietoenator.com Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7VQX-0002Zw-DJ for simple@ietf.org; Fri, 10 Feb 2006 05:22:58 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Feb 2006 11:09:16 +0100 Message-ID: <3ACC9A25264A684F82C71840111F9798011AE2B8@carrera.eu.tieto.com> Thread-Topic: problem with filters and resource lists Thread-Index: AcYuKgyo/5jUOR6cRNGQNCe1lInppg== To: X-OriginalArrivalTime: 10 Feb 2006 10:09:18.0308 (UTC) FILETIME=[0DE25A40:01C62E2A] X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Subject: [Simple] problem with filters and resource lists X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hello,=20 In draft-ietf-simple-event-filter-funct par. 4.1. is described how rls = server handles filters in subscription to resource list. Following = situation is not clear to me: I have 2 lists in one RLS (name it RLS1):=20 list1@example.com (bob@example.com, list2@example.com) list2@example.com (alice@biloxi.com, sarah@example.com) Then I have subscribe with filter: SUBSCRIBE sip:list1@example.com SIP/2.0 ... ... ... My current understanding is that the filter for alice will NOT be = propagated and will be lost, because: 1/ it will not be propagated in the subscribe to list2, because list2 is = under administrative control of RLS1. 2/ it will not be applied by the RLS1, because it is not under it's = administrative control This is similar to the example in the draft, but in the draft the lists = are in different RLSs - therefore the filter for alice is propagated in = the subscribe to list2. This seems like an error to me, because the result is different for 2 = lists in the same RLSs and in 2 different RLSs. Can someone explain this?=20 Thank you, Silvestr Peknik Software Specialist TietoEnator Czech Software Center Phone=A0+420 599 096 027 E-mail silvestr.peknik@tietoenator.com=A0=A0 =A0 Vystavni 292/13 CZ-709=A016 Ostrava =A0 www.tietoenator.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 10 06:55:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Wrg-0003A7-PJ; Fri, 10 Feb 2006 06:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Wrb-000378-6T for simple@megatron.ietf.org; Fri, 10 Feb 2006 06:55:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12706 for ; Fri, 10 Feb 2006 06:53:14 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7X4S-0005xQ-8Q for simple@ietf.org; Fri, 10 Feb 2006 07:08:24 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 108A31944A9 for ; Fri, 10 Feb 2006 12:54:35 +0100 (CET) Received: from [192.168.1.69] ([192.168.1.69]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2006 12:53:12 +0100 In-Reply-To: <3ACC9A25264A684F82C71840111F9798011AE2B8@carrera.eu.tieto.com> References: <3ACC9A25264A684F82C71840111F9798011AE2B8@carrera.eu.tieto.com> 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] problem with filters and resource lists Date: Fri, 10 Feb 2006 12:54:48 +0100 To: Silvestr.Peknik@tietoenator.com X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 10 Feb 2006 11:53:12.0584 (UTC) FILETIME=[91CD6080:01C62E38] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I guess you are referring to the following text: "If the URI indicated by the filter is for one resource whose URI is NOT under the RLS administrative control, the RLS propagates the filter to all the fanned out subscriptions sent to destinations outside the administrative domain of the RLS." This seems to have the limitation you mention below. Would the following text fix it? would it break anything else? "If the URI indicated by the filter is for one resource whose URI is NOT under the RLS administrative control, the RLS propagates the filter to all the fanned out." Hisham On Feb 10, 2006, at 11:09 AM, Silvestr.Peknik@tietoenator.com wrote: > Hello, > > In draft-ietf-simple-event-filter-funct par. 4.1. is described how rls=20= > server handles filters in subscription to resource list. Following=20 > situation is not clear to me: > > I have 2 lists in one RLS (name it RLS1): > list1@example.com (bob@example.com, list2@example.com) > list2@example.com (alice@biloxi.com, sarah@example.com) > > Then I have subscribe with filter: > > SUBSCRIBE sip:list1@example.com SIP/2.0 > ... > > > > ... > > > ... > > > > My current understanding is that the filter for alice will NOT be=20 > propagated and will be lost, because: > 1/ it will not be propagated in the subscribe to list2, because list2=20= > is under administrative control of RLS1. > 2/ it will not be applied by the RLS1, because it is not under it's=20 > administrative control > > This is similar to the example in the draft, but in the draft the=20 > lists are in different RLSs - therefore the filter for alice is=20 > propagated in the subscribe to list2. > > This seems like an error to me, because the result is different for 2=20= > lists in the same RLSs and in 2 different RLSs. > > Can someone explain this? > > Thank you, > > Silvestr Peknik > Software Specialist > > TietoEnator > Czech Software Center > Phone=A0+420 599 096 027 > E-mail silvestr.peknik@tietoenator.com=A0=A0 > =A0 > Vystavni 292/13 > CZ-709=A016 Ostrava > =A0 > www.tietoenator.com > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 10 07:18:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7XEg-0003Xp-N0; Fri, 10 Feb 2006 07:18:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7XEd-0003Wh-5Y for simple@megatron.ietf.org; Fri, 10 Feb 2006 07:18:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14309 for ; Fri, 10 Feb 2006 07:17:02 -0500 (EST) From: Silvestr.Peknik@tietoenator.com Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7XRb-0006kK-Jc for simple@ietf.org; Fri, 10 Feb 2006 07:32:13 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] problem with filters and resource lists Date: Fri, 10 Feb 2006 13:18:25 +0100 Message-ID: <3ACC9A25264A684F82C71840111F9798011AE3E1@carrera.eu.tieto.com> Thread-Topic: [Simple] problem with filters and resource lists Thread-Index: AcYuOM+QB8KzIP17Rw+Sp4n0nIEogAAAsvow To: X-OriginalArrivalTime: 10 Feb 2006 12:18:29.0124 (UTC) FILETIME=[19BB0440:01C62E3C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Yes, this is the problem. I guess your modification would solve the problem and should not break = anything, as filters targeted to URIs not matching any resources are = ignored. However my knowledge about this area is limited, I just started = to explore it. -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Friday, February 10, 2006 12:55 PM To: Peknik Silvestr Cc: simple@ietf.org Subject: Re: [Simple] problem with filters and resource lists I guess you are referring to the following text: "If the URI indicated by the filter is for one resource whose URI is NOT under the RLS administrative control, the RLS propagates the filter to all the fanned out subscriptions sent to destinations outside the administrative domain of the RLS." This seems to have the limitation you mention below. Would the following text fix it? would it break anything else? "If the URI indicated by the filter is for one resource whose URI is NOT under the RLS administrative control, the RLS propagates the filter to all the fanned out." Hisham On Feb 10, 2006, at 11:09 AM, Silvestr.Peknik@tietoenator.com wrote: > Hello, > > In draft-ietf-simple-event-filter-funct par. 4.1. is described how rls = > server handles filters in subscription to resource list. Following=20 > situation is not clear to me: > > I have 2 lists in one RLS (name it RLS1): > list1@example.com (bob@example.com, list2@example.com) > list2@example.com (alice@biloxi.com, sarah@example.com) > > Then I have subscribe with filter: > > SUBSCRIBE sip:list1@example.com SIP/2.0 > ... > > > > ... > > > ... > > > > My current understanding is that the filter for alice will NOT be=20 > propagated and will be lost, because: > 1/ it will not be propagated in the subscribe to list2, because list2=20 > is under administrative control of RLS1. > 2/ it will not be applied by the RLS1, because it is not under it's=20 > administrative control > > This is similar to the example in the draft, but in the draft the=20 > lists are in different RLSs - therefore the filter for alice is=20 > propagated in the subscribe to list2. > > This seems like an error to me, because the result is different for 2=20 > lists in the same RLSs and in 2 different RLSs. > > Can someone explain this? > > Thank you, > > Silvestr Peknik > Software Specialist > > TietoEnator > Czech Software Center > Phone=A0+420 599 096 027 > E-mail silvestr.peknik@tietoenator.com=A0=A0 > =A0 > Vystavni 292/13 > CZ-709=A016 Ostrava > =A0 > www.tietoenator.com > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 10 07:36:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7XVy-0001p0-HH; Fri, 10 Feb 2006 07:36:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7XVx-0001oc-GP for simple@megatron.ietf.org; Fri, 10 Feb 2006 07:36:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15518 for ; Fri, 10 Feb 2006 07:34:57 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7Xix-0007Hk-L9 for simple@ietf.org; Fri, 10 Feb 2006 07:50:08 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 10 Feb 2006 04:36:31 -0800 X-IronPort-AV: i="4.02,103,1139212800"; d="scan'208"; a="1775209787:sNHT32244600" 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 k1ACaVQJ028459; Fri, 10 Feb 2006 04:36:31 -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); Fri, 10 Feb 2006 04:36:30 -0800 Received: from [172.17.154.148] ([10.89.20.23]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 04:36:30 -0800 Message-ID: <43EC88CD.2090408@cisco.com> Date: Fri, 10 Feb 2006 07:36:29 -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: Jari Urpalainen Subject: Re: [Simple] Re: Other MIME type than xcap-el/attr References: <00de01c62be6$30d9cb50$a0020a0a@samsungk1o0rnf> <43EA6962.5010004@cisco.com> <1139475216.20654.44.camel@hed034-145.research.nokia.com> In-Reply-To: <1139475216.20654.44.camel@hed034-145.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2006 12:36:30.0289 (UTC) FILETIME=[9E27B410:01C62E3E] X-Spam-Score: 2.0 (++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org inline. Jari Urpalainen wrote: > Inline -- > > On Wed, 2006-02-08 at 16:57 -0500, ext Jonathan Rosenberg wrote: > >>The intent was that its not meant to be extended, and that nothing else >>would be used. Do you have a use case or need for something else? >> >>Thanks, >>Jonathan R. >> > > well I had another impression. E.g. with multi-insert one would use > multiple elements in the body, would it be the same content-type than > xcap-el+xml, for example ? Yes; it would just have multiple elements. > Anyhow, I don't much care if some new > content-types are defined by some new extensions, because they don't > break the base spec in anyway, imo. They don't; my point though was that unless you were doing something substanially different, xcap-el+xml really ought to suffice. I'd still like to understand what the use case was around the question. That is, you'll negotiate response > type with Accept-header and even in some cases you might use request > body as well and XCAP capabilities doc may list this extension tag. > Although XCAP isn't an XML database or something like that, a really > cool extension would be, for example, XQuery like requests over docs. Right - like I said, unless you're doing something pretty radically different, xcap-el+xml will suffice. > So > I don't see a problem for a future extension to define some new > semantics with new mime-types (although I don't have an intention to > propose something now, no ;-)). Also one could argue that some BNF > extensions (which are now explicitly allowed) are useless without the > ability to have new mime-types as well. There I disagree. The new extensions to the URI are meant to allow different ways of selecting elements and attributes, but the net result is that what comes back is still elements and attributes. -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 Fri Feb 10 09:17:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Z5V-0005Q4-91; Fri, 10 Feb 2006 09:17:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Z5T-0005Pz-KF for simple@megatron.ietf.org; Fri, 10 Feb 2006 09:17:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22646 for ; Fri, 10 Feb 2006 09:15:44 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7ZIT-00025d-Ab for simple@ietf.org; Fri, 10 Feb 2006 09:30:55 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 0FA6119449E for ; Fri, 10 Feb 2006 15:17:16 +0100 (CET) Received: from [192.168.1.69] ([192.168.1.69]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2006 15:15:51 +0100 In-Reply-To: <3ACC9A25264A684F82C71840111F9798011AE3E1@carrera.eu.tieto.com> References: <3ACC9A25264A684F82C71840111F9798011AE3E1@carrera.eu.tieto.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <4e09068301e436a056cf7d56ade64a44@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Simple] problem with filters and resource lists Date: Fri, 10 Feb 2006 15:17:29 +0100 To: X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 10 Feb 2006 14:15:51.0136 (UTC) FILETIME=[7F18C600:01C62E4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org If there are no objections, I will change the text in the author's 48=20 hours. The removal of the last part of this paragraph fixes the problem=20= and I believe does not affect any other parts of the system. Regards, Hisham On Feb 10, 2006, at 1:18 PM, wrote: > Yes, this is the problem. > > I guess your modification would solve the problem and should not break=20= > anything, as filters targeted to URIs not matching any resources are=20= > ignored. However my knowledge about this area is limited, I just=20 > started to explore it. > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Friday, February 10, 2006 12:55 PM > To: Peknik Silvestr > Cc: simple@ietf.org > Subject: Re: [Simple] problem with filters and resource lists > > I guess you are referring to the following text: > > "If the URI indicated by the filter is for one resource whose URI is > NOT under the RLS administrative control, the RLS propagates the > filter to all the fanned out subscriptions sent to destinations > outside the administrative domain of the RLS." > > This seems to have the limitation you mention below. > > Would the following text fix it? would it break anything else? > > "If the URI indicated by the filter is for one resource whose URI is > NOT under the RLS administrative control, the RLS propagates the > filter to all the fanned out." > > > Hisham > > On Feb 10, 2006, at 11:09 AM, Silvestr.Peknik@tietoenator.com wrote: > >> Hello, >> >> In draft-ietf-simple-event-filter-funct par. 4.1. is described how = rls >> server handles filters in subscription to resource list. Following >> situation is not clear to me: >> >> I have 2 lists in one RLS (name it RLS1): >> list1@example.com (bob@example.com, list2@example.com) >> list2@example.com (alice@biloxi.com, sarah@example.com) >> >> Then I have subscribe with filter: >> >> SUBSCRIBE sip:list1@example.com SIP/2.0 >> ... >> >> >> >> ... >> >> >> ... >> >> >> >> My current understanding is that the filter for alice will NOT be >> propagated and will be lost, because: >> 1/ it will not be propagated in the subscribe to list2, because list2 >> is under administrative control of RLS1. >> 2/ it will not be applied by the RLS1, because it is not under it's >> administrative control >> >> This is similar to the example in the draft, but in the draft the >> lists are in different RLSs - therefore the filter for alice is >> propagated in the subscribe to list2. >> >> This seems like an error to me, because the result is different for 2 >> lists in the same RLSs and in 2 different RLSs. >> >> Can someone explain this? >> >> Thank you, >> >> Silvestr Peknik >> Software Specialist >> >> TietoEnator >> Czech Software Center >> Phone=A0+420 599 096 027 >> E-mail silvestr.peknik@tietoenator.com=A0=A0 >> =A0 >> Vystavni 292/13 >> CZ-709=A016 Ostrava >> =A0 >> www.tietoenator.com >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 10 11:37:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7bHA-00030M-5J; Fri, 10 Feb 2006 11:37:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7bH8-00030H-Ur for simple@megatron.ietf.org; Fri, 10 Feb 2006 11:37:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06105 for ; Fri, 10 Feb 2006 11:35:55 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7bUB-0007sD-3P for simple@ietf.org; Fri, 10 Feb 2006 11:51:07 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 10 Feb 2006 08:37:30 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,103,1139212800"; d="scan'208"; a="21616198:sNHT26408624" 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 k1AGakPw004085; Fri, 10 Feb 2006 11:37:27 -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); Fri, 10 Feb 2006 11:37:22 -0500 Received: from [161.44.79.51] ([161.44.79.51]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 11:37:22 -0500 Message-ID: <43ECC141.6070900@cisco.com> Date: Fri, 10 Feb 2006 11:37:21 -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] OMA and draft-niemi-simple-chat-03.txt References: <43EB8FF6.9050200@cisco.com> <43EC440C.4070802@nokia.com> In-Reply-To: <43EC440C.4070802@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2006 16:37:22.0289 (UTC) FILETIME=[4437E610:01C62E60] X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: 7bit Cc: Dean Willis , Mary Barnes , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Aki Niemi wrote: > Paul, > > I'm not half as concerned about this balkanization of conferencing > features as you appear to be. In fact, I think what you describe is only > a problem if we look at things with the standards-committee glasses on. My concern is not one of standards-committee turf. My concern is that I want to be able to use multiple media in a conference - say voice and IM, or PTT and IM. And I don't want to be forced to set up a different call to the focus for each medium. All the IM vendors are starting to offer voice as well. So the combination has to work well. Effectively what you are proposing is an in-band mixer control protocol for a conference involving MSRP. How does that fit in to a conference where I have voice and video as well as MSRP? Should we develop a separate in-band mixer control protocol for each media type? Maybe that is the right answer. But if it isn't the right answer for all media that make sense in a conference, then why is it the right answer for one of them? Note that in the case of Jabber, the IM channel and the signaling channel are the same. So for them the issues are different. Even then, how do they handle voice mixer control? Can I send a voice whisper to a nickname? > Of course then, everything even remotely resembling conferencing needs > to be dumped to XCON, which we are now eagerly waiting to get their act > together so we can make forward progress. > > Why I think MSRP chat is important and needs to get done *now* is that > without multi-user chat, MSRP will pale in comparison to every other > chat out there. Check out IRC or Jabber MUC. They both have nicknames, > private messages (!=sidebar) and sidebars. Done in chat-specific way. > > I happen to believe we can make these features in a chat specific way in > MSRP and whenever XCON gets the generic mechanisms ready, we can migrate > to them. So where's the problem? Well, if this is intended as a short term solution until XCON is done, then lets admit that and decide if that is a good way forward. That does cast a different light on it. I'm not sure what my opinion on that is. I agree that XCON hasn't been progressing well, and it would be good to get MSRP deployed. But I fear that once started down the wrong road it is hard to get back on the right road. Paul > Cheers, > Aki > > ext Paul Kyzivat wrote: > >> I'm in violent agreement with Mary and Hisham. >> >> There are a number of things that concern me: >> >> - the balkanization of media, in that certain features that >> ought to be media independent are instead implemented in >> a unique way for this one medium. >> >> - I never liked distsend, for the reason above - it is an >> end run around sidebars. But in addition to that it has >> been recently pointed out on the list that it can't work, >> because only SEND is chunked in MSRP. >> >> - as Mary mentions, nicknames aren't just an IM issue. >> (Balkanization again.) And getting the semantics of >> nicknames right may be tricky. (Within a particular >> context (greater than a single conference session) >> I don't want the same nickname to be grabbed by >> different people too easily.) >> >> Paul >> >> Mary Barnes wrote: >> >>> When this draft was discussed previously, the discussion was that the >>> aliasing (nickname) problem was a more general SIP problem and it was >>> proposed that a team be assembled to address that general problem. I'm >>> assuming that team never formed or if they did are there any conclusions >>> to share? >>> And, I thought the sidebar functionality was suggested to be supported >>> by the work in XCON. >>> I'm in agreement with Hisham in that I'd rather not see a specialized >>> solution for OMA pushed through when general solutions are more >>> appropriate. >>> Mary. >>> >>> -----Original Message----- >>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf >>> Of Dean Willis >>> Sent: Thursday, February 09, 2006 12:05 PM >>> To: Hisham Khartabil >>> Cc: Simple WG >>> Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt >>> >>> >>> >>> I just had a chat with some of the OMA messaging people, and the >>> main thing they're dealing with is sidebar conversations in MSRP >>> conferences. They also want dynamic alias negotiation. They'll send >>> some requirements docs and supporting material to the list in the >>> next few days. >>> >>> It would be nice to find a path towards a solution that works for >>> everybody involved. >>> >>> -- >>> Dean Willis >>> IETF liaison to OMA. >>> >>> On Feb 9, 2006, at 11:00 AM, Hisham Khartabil wrote: >>> >>> >>>> This draft is not mature at all and I hope OMA don't force SIMPLE >>>> to stick to whatever is in there just because that's how they >>>> defined their service to be (some of us have the opinion that >>>> whatever is in there now is broken and does not work with MSRP >>>> properly). >>>> >>>> Thanks, >>>> Hisham >>>> >>>> On Feb 9, 2006, at 3:20 PM, Dean Willis wrote: >>>> >>>> >>>>> OMA's messaging working group is all abuzz about their alleged >>>>> need for draft-niemi-simple-chat-03.txt to become an RFC. >>>>> >>>>> I'm trying to figure exactly which part of this draft they think >>>>> they need, and I'll get back with you when I have more >>>>> information. So far, they've told me that their entire chat room >>>>> approach is built around this draft. I presume they're using the >>>>> MSRP extension in this draft, but don't know for sure. >>>>> >>>>> However, it may be time to give this draft another read, and see >>>>> what we think about the problem set it's trying to solve -- N-way >>>>> centralized MSRP conferencing with sidebars. >>>>> >>>>> -- >>>>> Dean >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> _______________________________________________ >> 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 Feb 10 11:42:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7bLe-0003fZ-TT; Fri, 10 Feb 2006 11:42:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7bLc-0003f0-6m for simple@megatron.ietf.org; Fri, 10 Feb 2006 11:42:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06324 for ; Fri, 10 Feb 2006 11:40:32 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7bYb-0007zP-7k for simple@ietf.org; Fri, 10 Feb 2006 11:55:44 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1AGfnf10211; Fri, 10 Feb 2006 11:41:49 -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] OMA and draft-niemi-simple-chat-03.txt Date: Fri, 10 Feb 2006 10:41:47 -0600 Message-ID: Thread-Topic: [Simple] OMA and draft-niemi-simple-chat-03.txt Thread-Index: AcYuFC5zyhX5hra8SaKBGGD8yfcv3wASpMaQ From: "Mary Barnes" To: "Aki Niemi" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: Simple WG , Dean Willis X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Aki, There is an alternative proposal using MSRP for conferencing in XCON that discusses sidebars: http://www.ietf.org/internet-drafts/draft-boulton-xcon-msrp-conferencing -02.txt This document refers to the sidebar functionality provided by the XCON framework (in section 9.4) http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-02.txt Certainly, this work is incomplete with more detail being required in the example and we are seeking feedback on this approach for sidebars.=20 I think discussion of sidebars should continue on the XCON WG mailing list.=20 That all said, one of the other issues I raised was based on Dean's subsequent email that OMA wanted the aliasing and I am also (and perhaps more so) concerned about that not being provided in a generalized form to meet requirements of other applications. For example, a similar idea has been discussed in the context of the conference control protocol on the XCON WG mailing list in terms of providing some sort of abbreviated URI or handle. http://www1.ietf.org/mail-archive/web/xcon/current/msg01648.html And, this all brings us back to another comment made on this work in that "we need a way to manage the overlap between this work in the three working groups that are discussing it -- xcon, simple, and sipping." =20 Mary -----Original Message----- From: Aki Niemi [mailto:aki.niemi@nokia.com]=20 Sent: Friday, February 10, 2006 1:32 AM To: Barnes, Mary [RICH2:B601:EXCH] Cc: Dean Willis; Hisham Khartabil; Simple WG Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt ext Mary Barnes wrote: > I'm in agreement with Hisham in that I'd rather not see a specialized > solution for OMA pushed through when general solutions are more > appropriate.=20 We'll be more than happy to incorporate the generalized sidebar=20 functionality in; is there an I-D I can reference here? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 10 11:55:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7bYI-0001Ey-Ak; Fri, 10 Feb 2006 11:55:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7bYE-0001Db-Jc for simple@megatron.ietf.org; Fri, 10 Feb 2006 11:55:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07335 for ; Fri, 10 Feb 2006 11:53:25 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7bl7-0008S0-Jx for simple@ietf.org; Fri, 10 Feb 2006 12:08:38 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1AGsPf14602; Fri, 10 Feb 2006 11:54:25 -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] OMA and draft-niemi-simple-chat-03.txt Date: Fri, 10 Feb 2006 10:54:18 -0600 Message-ID: Thread-Topic: [Simple] OMA and draft-niemi-simple-chat-03.txt Thread-Index: AcYuYEy3cKIyV/6HS1GE6ScYlNrx0AAAQN/A From: "Mary Barnes" To: "Paul Kyzivat" , "Aki Niemi" X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Content-Transfer-Encoding: quoted-printable Cc: Simple WG , Dean Willis X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I agree with most of Pauls' comments and just have a few additional comments embedded below [MB]. Mary -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Friday, February 10, 2006 10:37 AM To: Aki Niemi Cc: Barnes, Mary [RICH2:B601:EXCH]; Simple WG; Dean Willis Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt Aki Niemi wrote: > Paul, >=20 > I'm not half as concerned about this balkanization of conferencing=20 > features as you appear to be. In fact, I think what you describe is only=20 > a problem if we look at things with the standards-committee glasses on.=20 My concern is not one of standards-committee turf. My concern is that I want to be able to use multiple media in a=20 conference - say voice and IM, or PTT and IM. And I don't want to be=20 forced to set up a different call to the focus for each medium. All the=20 IM vendors are starting to offer voice as well. So the combination has=20 to work well. Effectively what you are proposing is an in-band mixer control protocol=20 for a conference involving MSRP. How does that fit in to a conference=20 where I have voice and video as well as MSRP? Should we develop a separate in-band mixer control protocol for each=20 media type? Maybe that is the right answer. But if it isn't the right=20 answer for all media that make sense in a conference, then why is it the right answer for one of them? Note that in the case of Jabber, the IM channel and the signaling=20 channel are the same. So for them the issues are different. Even then,=20 how do they handle voice mixer control? Can I send a voice whisper to a=20 nickname? > Of course then, everything even remotely resembling conferencing needs > to be dumped to XCON, which we are now eagerly waiting to get their act=20 > together so we can make forward progress. >=20 > Why I think MSRP chat is important and needs to get done *now* is that > without multi-user chat, MSRP will pale in comparison to every other=20 > chat out there. Check out IRC or Jabber MUC. They both have nicknames, > private messages (!=3Dsidebar) and sidebars. Done in chat-specific = way. >=20 > I happen to believe we can make these features in a chat specific way in=20 > MSRP and whenever XCON gets the generic mechanisms ready, we can migrate=20 > to them. So where's the problem? Well, if this is intended as a short term solution until XCON is done,=20 then lets admit that and decide if that is a good way forward. That does cast a different light on it. I'm not sure what my opinion on that is. I agree that XCON hasn't been progressing well, and it would be good to=20 get MSRP deployed. But I fear that once started down the wrong road it=20 is hard to get back on the right road. [MB] I don't think it's productive to be bashing XCON considering that it's really not progressed any slower than alot of other work underway. We are making progress in XCON and at this point we need additional feedback from WG members. The framework document has been available for feedback for quite some time. My concern is that if we decide that this draft is a "short term" solution, I don't think we've done a good job of keeping short term solutions short term (i.e., all the ones I can think of are still around and likely to stay that way - e.g., PAI and pre-MIDCOM work). That all said, I don't think this approach would be incompatible with later providing the functionality with XCON. However, I think the more important hurdle is whether this functionality should be provided in this manner (by changing MSRP) when it can be provided in a more general form with the XCON model. I think it's very subjective to say that this work has a better chance of being completed in SIMPLE than in XCON.=20 [/MB]=20 Paul > Cheers, > Aki >=20 > ext Paul Kyzivat wrote: >=20 >> I'm in violent agreement with Mary and Hisham. >> >> There are a number of things that concern me: >> >> - the balkanization of media, in that certain features that >> ought to be media independent are instead implemented in >> a unique way for this one medium. >> >> - I never liked distsend, for the reason above - it is an >> end run around sidebars. But in addition to that it has >> been recently pointed out on the list that it can't work, >> because only SEND is chunked in MSRP. >> >> - as Mary mentions, nicknames aren't just an IM issue. >> (Balkanization again.) And getting the semantics of >> nicknames right may be tricky. (Within a particular >> context (greater than a single conference session) >> I don't want the same nickname to be grabbed by >> different people too easily.) >> >> Paul >> >> Mary Barnes wrote: >> >>> When this draft was discussed previously, the discussion was that the >>> aliasing (nickname) problem was a more general SIP problem and it was >>> proposed that a team be assembled to address that general problem. I'm >>> assuming that team never formed or if they did are there any conclusions >>> to share? >>> And, I thought the sidebar functionality was suggested to be supported >>> by the work in XCON. >>> I'm in agreement with Hisham in that I'd rather not see a specialized >>> solution for OMA pushed through when general solutions are more >>> appropriate. >>> Mary. >>> >>> -----Original Message----- >>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf >>> Of Dean Willis >>> Sent: Thursday, February 09, 2006 12:05 PM >>> To: Hisham Khartabil >>> Cc: Simple WG >>> Subject: Re: [Simple] OMA and draft-niemi-simple-chat-03.txt >>> >>> >>> >>> I just had a chat with some of the OMA messaging people, and the=20 >>> main thing they're dealing with is sidebar conversations in MSRP =20 >>> conferences. They also want dynamic alias negotiation. They'll send >>> some requirements docs and supporting material to the list in the =20 >>> next few days. >>> >>> It would be nice to find a path towards a solution that works for =20 >>> everybody involved. >>> >>> --=20 >>> Dean Willis >>> IETF liaison to OMA. >>> >>> On Feb 9, 2006, at 11:00 AM, Hisham Khartabil wrote: >>> >>> >>>> This draft is not mature at all and I hope OMA don't force SIMPLE =20 >>>> to stick to whatever is in there just because that's how they =20 >>>> defined their service to be (some of us have the opinion that =20 >>>> whatever is in there now is broken and does not work with MSRP =20 >>>> properly). >>>> >>>> Thanks, >>>> Hisham >>>> >>>> On Feb 9, 2006, at 3:20 PM, Dean Willis wrote: >>>> >>>> >>>>> OMA's messaging working group is all abuzz about their alleged =20 >>>>> need for draft-niemi-simple-chat-03.txt to become an RFC. >>>>> >>>>> I'm trying to figure exactly which part of this draft they think =20 >>>>> they need, and I'll get back with you when I have more =20 >>>>> information. So far, they've told me that their entire chat room =20 >>>>> approach is built around this draft. I presume they're using the =20 >>>>> MSRP extension in this draft, but don't know for sure. >>>>> >>>>> However, it may be time to give this draft another read, and see =20 >>>>> what we think about the problem set it's trying to solve -- N-way >>>>> centralized MSRP conferencing with sidebars. >>>>> >>>>> --=20 >>>>> Dean >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Feb 12 06:08:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8F5w-0002Bm-MY; Sun, 12 Feb 2006 06:08:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8F5v-0002Bh-Hy for simple@megatron.ietf.org; Sun, 12 Feb 2006 06:08:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08574 for ; Sun, 12 Feb 2006 06:06:58 -0500 (EST) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8FJJ-0007PO-SI for simple@ietf.org; Sun, 12 Feb 2006 06:22:34 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id k1CB8XQk207684 for ; Sun, 12 Feb 2006 11:08:33 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1CB8Zru178964 for ; Sun, 12 Feb 2006 12:08:35 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k1CB8XMK025962 for ; Sun, 12 Feb 2006 12:08:33 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k1CB8Xra025959 for ; Sun, 12 Feb 2006 12:08:33 +0100 To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Avshalom Houri Message-ID: Date: Sun, 12 Feb 2006 13:08:34 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/02/2006 13:08:35, Serialize complete at 12/02/2006 13:08:35 X-Spam-Score: 0.8 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Subject: [Simple] Fw: [Sip-implementors] Is draft-ietf-simple-rpid-10 missing an xs:import? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============1774774249==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============1774774249== Content-Type: multipart/alternative; boundary="=_alternative 003D24D1C2257113_=" This is a multipart message in MIME format. --=_alternative 003D24D1C2257113_= Content-Type: text/plain; charset="US-ASCII" Appeared in sip implementors. What do you think? Thanks Avshalom ----- Forwarded by Avshalom Houri/Haifa/IBM on 12/02/2006 13:06 ----- Rhys D Ulerich Sent by: sip-implementors-bounces@cs.columbia.edu 09/02/2006 21:04 To sip-implementors@cs.columbia.edu cc Subject [Sip-implementors] Is draft-ietf-simple-rpid-10 missing an xs:import? Hi all, >From mucking with the XSD within draft-ietf-simple-rpid-10 section 5.1, it looks like it may be missing a statement like: My IDE balks at the following xs:include of common-schema.xsd unless I add that xs:import. Compare with similar declarations within RFC 3863, draft-ietf-simple-presence-data-model, etc. Can anyone confirm? - Rhys _______________________________________ Rhys Ulerich IBM _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors --=_alternative 003D24D1C2257113_= Content-Type: text/html; charset="US-ASCII"
Appeared in sip implementors.
What do you think?

Thanks
Avshalom
----- Forwarded by Avshalom Houri/Haifa/IBM on 12/02/2006 13:06 -----
Rhys D Ulerich <rhys@us.ibm.com>
Sent by: sip-implementors-bounces@cs.columbia.edu

09/02/2006 21:04

To
sip-implementors@cs.columbia.edu
cc
Subject
[Sip-implementors] Is draft-ietf-simple-rpid-10 missing an        xs:import?





Hi all,

>From mucking with the XSD within draft-ietf-simple-rpid-10 section 5.1, it
looks like it may be missing a statement like:
   <xs:import namespace="http://www.w3.org/XML/1998/namespace"
              schemaLocation="http://www.w3.org/2001/xml.xsd"/>
My IDE balks at the following xs:include of common-schema.xsd unless I add
that xs:import.

Compare with similar declarations within RFC 3863,
draft-ietf-simple-presence-data-model, etc.

Can anyone confirm?

- Rhys
_______________________________________
Rhys Ulerich
IBM
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
 --=_alternative 003D24D1C2257113_=-- --===============1774774249== 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 --===============1774774249==-- From simple-bounces@ietf.org Sun Feb 12 09:01:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8Hn4-0001Jj-Vx; Sun, 12 Feb 2006 09:01:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8Hn3-0001Je-Fi for simple@megatron.ietf.org; Sun, 12 Feb 2006 09:01:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18685 for ; Sun, 12 Feb 2006 08:59:41 -0500 (EST) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8I0S-0003UY-VM for simple@ietf.org; Sun, 12 Feb 2006 09:15:17 -0500 Received: from ep_mmp1 (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 <0IUK005E7UY1AD@mailout1.samsung.com> for simple@ietf.org; Sun, 12 Feb 2006 23:01:13 +0900 (KST) Received: from samsungk1o0rnf ([105.253.11.6]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IUK005ILUXSHE@mmp1.samsung.com> for simple@ietf.org; Sun, 12 Feb 2006 23:01:13 +0900 (KST) Date: Sun, 12 Feb 2006 22:55:39 +0900 From: Jaekwon Oh Subject: Re: [Simple] Re: Other MIME type than xcap-el/attr To: Jari Urpalainen , Jonathan Rosenberg Message-id: <001601c62fdc$af68f640$b604a8c0@samsungk1o0rnf> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Mailer: Microsoft Outlook Express 6.00.2900.2527 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00de01c62be6$30d9cb50$a0020a0a@samsungk1o0rnf> <43EA6962.5010004@cisco.com> <1139475216.20654.44.camel@hed034-145.research.nokia.com> <43EC88CD.2090408@cisco.com> X-Spam-Score: 2.0 (++) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7BIT Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hello, Thank you for response and find my response inline. BR, Jaekwon Oh Global Stanadards & Research Samsung Electronics, Co. Ltd. TEL +82 31 279 5086 CP +82 16 9530 5086 FAX +82 31 279 5130 jaekwon.oh@samsung.com ----- Original Message ----- From: "Jonathan Rosenberg" To: "Jari Urpalainen" Cc: "Jaekwon Oh" ; "Simple WG" Sent: Friday, February 10, 2006 9:36 PM Subject: Re: [Simple] Re: Other MIME type than xcap-el/attr > inline. > > Jari Urpalainen wrote: > >> Inline -- >> >> On Wed, 2006-02-08 at 16:57 -0500, ext Jonathan Rosenberg wrote: >> >>>The intent was that its not meant to be extended, and that nothing else >>>would be used. Do you have a use case or need for something else? >>> >>>Thanks, >>>Jonathan R. >>> For namespace binding information, it is understood that namespace node retrival as defined in xcap-08 is quite clean solution. However, as the operation of grabbing a wireless channel for a tranascation is delay-prone in wireless media, the intended use case is to optimize the number of transaction in getting the namespace binding infomration by allowing the fragment to contain local namespace binding within itself. The following is an example of such fragment body: Content-Type: application/xxxxxx+xml urn:ietf:params:xml:ns:rls-services urn:ietf:params:xml:ns:resource-lists http://example.com/foo presence In the above example, the will contain the local namespace binding informatin as identified by all namespace node operation of '.../namespace::* under the element targeted. This approach allow the local namespace binding information to be within the fragment itself. Also, this approach would separate the local namespace binding information from the fragment body targeted. Thus, it could avoid the document cluttering by superfuluous local namespace binding information in the fragment body and also keep intact, any local namespace declaration or reclaration on an element. However, as this optimization is purposed to cope with the particular environment of wireless media rather than generic one, it seems appropriate to extend basic xcap-el/attr MIME type by defining a new MIME type, *if allowed*, than trying to directly extend xcap-el/attr MIME type. >> >> well I had another impression. E.g. with multi-insert one would use >> multiple elements in the body, would it be the same content-type than >> xcap-el+xml, for example ? > > Yes; it would just have multiple elements. > >> Anyhow, I don't much care if some new >> content-types are defined by some new extensions, because they don't >> break the base spec in anyway, imo. > > They don't; my point though was that unless you were doing something > substanially different, xcap-el+xml really ought to suffice. I'd still > like to understand what the use case was around the question. > > > That is, you'll negotiate response >> type with Accept-header and even in some cases you might use request >> body as well and XCAP capabilities doc may list this extension tag. >> Although XCAP isn't an XML database or something like that, a really >> cool extension would be, for example, XQuery like requests over docs. > > Right - like I said, unless you're doing something pretty radically > different, xcap-el+xml will suffice. > In fact, there's another use case of 'search', where the response fragment would contain the result of 'search' operation on the targeted. Considering there could be multiple results per the search operation, there are another challenge in xcap-08. The xcap node selector allows just one or no match. In other words, one or no context node, not allowing multiple context nodes as the result of node selector. So, it is also questionable whether it is possible to bend such xcap node selector constraints with the extension selector that is newly introduced in xcap-08. But, this is another issue... > >> So >> I don't see a problem for a future extension to define some new >> semantics with new mime-types (although I don't have an intention to >> propose something now, no ;-)). Also one could argue that some BNF >> extensions (which are now explicitly allowed) are useless without the >> ability to have new mime-types as well. > > There I disagree. The new extensions to the URI are meant to allow > different ways of selecting elements and attributes, but the net result > is that what comes back is still elements and attributes. > Please understand that the question here is *not* to propose something new, rather is to confirm whether a new MIME type for element/attr is allowed in xcap. Thank you. > -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 Mon Feb 13 03:55:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8ZUb-0000yX-LZ; Mon, 13 Feb 2006 03:55:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8ZUY-0000yA-JU for simple@megatron.ietf.org; Mon, 13 Feb 2006 03:55:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26616 for ; Mon, 13 Feb 2006 03:53:46 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8Zi4-000844-9O for simple@ietf.org; Mon, 13 Feb 2006 04:09:33 -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 k1D8ZFT5003116; Mon, 13 Feb 2006 10:35:18 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 10:35:48 +0200 Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 13 Feb 2006 10:35:47 +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 k1D8ZkC11121; Mon, 13 Feb 2006 10:35:46 +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 442ED93B6A; Mon, 13 Feb 2006 10:35:46 +0200 (EET) Subject: Re: [Simple] Re: Other MIME type than xcap-el/attr From: Jari Urpalainen To: ext Jonathan Rosenberg In-Reply-To: <43EC88CD.2090408@cisco.com> References: <00de01c62be6$30d9cb50$a0020a0a@samsungk1o0rnf> <43EA6962.5010004@cisco.com> <1139475216.20654.44.camel@hed034-145.research.nokia.com> <43EC88CD.2090408@cisco.com> Content-Type: text/plain Date: Mon, 13 Feb 2006 10:35:46 +0200 Message-Id: <1139819746.26644.53.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: 13 Feb 2006 08:35:47.0746 (UTC) FILETIME=[7CF7C820:01C63078] X-Spam-Score: 2.0 (++) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Fri, 2006-02-10 at 07:36 -0500, ext Jonathan Rosenberg wrote: > inline. > > Jari Urpalainen wrote: > > > Inline -- > > > > On Wed, 2006-02-08 at 16:57 -0500, ext Jonathan Rosenberg wrote: > > > >>The intent was that its not meant to be extended, and that nothing else > >>would be used. Do you have a use case or need for something else? > >> > >>Thanks, > >>Jonathan R. > >> > > > > well I had another impression. E.g. with multi-insert one would use > > multiple elements in the body, would it be the same content-type than > > xcap-el+xml, for example ? > > Yes; it would just have multiple elements. > hmm. while I agree that this is certainly possible with this weird xml ;-) it is imo worth a note somewhere because in general this is not possible. > > Anyhow, I don't much care if some new > > content-types are defined by some new extensions, because they don't > > break the base spec in anyway, imo. > > They don't; my point though was that unless you were doing something > substanially different, xcap-el+xml really ought to suffice. I'd still > like to understand what the use case was around the question. > > > That is, you'll negotiate response > > type with Accept-header and even in some cases you might use request > > body as well and XCAP capabilities doc may list this extension tag. > > Although XCAP isn't an XML database or something like that, a really > > cool extension would be, for example, XQuery like requests over docs. > > Right - like I said, unless you're doing something pretty radically > different, xcap-el+xml will suffice. > XQuery might be radical, I'd say it is complex and computer intensive, but I would not like to forbid anticipated possible future extensions, if there's no real technical reason behind prohibiting them. > > > So > > I don't see a problem for a future extension to define some new > > semantics with new mime-types (although I don't have an intention to > > propose something now, no ;-)). Also one could argue that some BNF > > extensions (which are now explicitly allowed) are useless without the > > ability to have new mime-types as well. > > There I disagree. The new extensions to the URI are meant to allow > different ways of selecting elements and attributes, but the net result > is that what comes back is still elements and attributes. > > -Jonathan R. > In addition to elements and attributes (where element patching covers undoubtedly over 90 % of the use cases, in general), text, comment, processing instructions and namespace declarations could be allowed with an extension specification as well. As an example, namespace declarations could be added with a namespace axis selector: PUT ...~~/root/namespace::prefix "uri:test" A very similar (and trivial) solution than attribute selections. The biggest difference being there's no abbreviated selector. Text nodes could be allowed as well: PUT ...~~/root/text() "new replaced text" What is difficult with them (as well as with elements, comments and PIs) is the exact positioning of new nodes (if there are several siblings). One really unambiguous solution is to use XPath "node()" function within predicates. "node()" selects all child nodes of the context element, i.e. child text, elements, comments and PIs. So a request like: PUT ...~~/root/node()[3][self::text()] "added or replaced text at node position 3" will require that the third child node of must be a text node. If the current 3. node is not a text node, it will be added there. This could be used also to maintain pretty printing style. Comments could be added similarly, PIs have a name. Certainly there are drawbacks, e.g. blind updates not possible because of positional predicates, some complexity etc. But I really don't see a point for disallowing these kind of possible future extensions. Sure they are not amongst the most needed features, but adding these will not break the base spec anyway. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 13 05:46:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8bDV-0001IU-Ag; Mon, 13 Feb 2006 05:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8bD8-0001EN-Ac for simple@megatron.ietf.org; Mon, 13 Feb 2006 05:45:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07960 for ; Mon, 13 Feb 2006 05:43:53 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8bQj-0003Ue-4o for simple@ietf.org; Mon, 13 Feb 2006 05:59:41 -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 k1DAj06h031262; Mon, 13 Feb 2006 12:45:03 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 12:45:28 +0200 Received: from mgw-int1.ntc.nokia.com ([172.21.143.96]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 13 Feb 2006 12:45:28 +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 k1DAjQb26124; Mon, 13 Feb 2006 12:45:26 +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 0F4E093B75; Mon, 13 Feb 2006 12:45:26 +0200 (EET) Subject: Re: [Simple] Re: Other MIME type than xcap-el/attr From: Jari Urpalainen To: ext Jaekwon Oh In-Reply-To: <001601c62fdc$af68f640$b604a8c0@samsungk1o0rnf> References: <00de01c62be6$30d9cb50$a0020a0a@samsungk1o0rnf> <43EA6962.5010004@cisco.com> <1139475216.20654.44.camel@hed034-145.research.nokia.com> <43EC88CD.2090408@cisco.com> <001601c62fdc$af68f640$b604a8c0@samsungk1o0rnf> Content-Type: text/plain Date: Mon, 13 Feb 2006 12:45:25 +0200 Message-Id: <1139827525.26644.94.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: 13 Feb 2006 10:45:28.0055 (UTC) FILETIME=[9A64B870:01C6308A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Sun, 2006-02-12 at 22:55 +0900, ext Jaekwon Oh wrote: > Hello, > > Thank you for response and find my response inline. > > BR, > Jaekwon Oh > > Global Stanadards & Research > Samsung Electronics, Co. Ltd. > TEL +82 31 279 5086 > CP +82 16 9530 5086 > FAX +82 31 279 5130 > jaekwon.oh@samsung.com > > > ----- Original Message ----- > From: "Jonathan Rosenberg" > To: "Jari Urpalainen" > Cc: "Jaekwon Oh" ; "Simple WG" > Sent: Friday, February 10, 2006 9:36 PM > Subject: Re: [Simple] Re: Other MIME type than xcap-el/attr > > > > inline. > > > > Jari Urpalainen wrote: > > > >> Inline -- > >> > >> On Wed, 2006-02-08 at 16:57 -0500, ext Jonathan Rosenberg wrote: > >> > >>>The intent was that its not meant to be extended, and that nothing else > >>>would be used. Do you have a use case or need for something else? > >>> > >>>Thanks, > >>>Jonathan R. > >>> > > For namespace binding information, it is understood that namespace node retrival as defined in xcap-08 is quite clean solution. However, as the operation of grabbing a wireless channel for a tranascation is delay-prone in wireless media, the intended use case is to optimize the number of transaction in getting the namespace binding infomration by allowing the fragment to contain local namespace binding within itself. The following is an example of such fragment body: > > Content-Type: application/xxxxxx+xml > > > urn:ietf:params:xml:ns:rls-services > urn:ietf:params:xml:ns:resource-lists > http://example.com/foo > > > > xmlns:xxxx="......(local namespace declaration or local redeclaration, if any)" > > > > > > > presence > > > > > In the above example, the will contain the local namespace binding informatin as identified by all namespace node operation of '.../namespace::* under the element targeted. This approach allow the local namespace binding information to be within the fragment itself. Also, this approach would separate the local namespace binding information from the fragment body targeted. Thus, it could avoid the document cluttering by superfuluous local namespace binding information in the fragment body and also keep intact, any local namespace declaration or reclaration on an element. > > However, as this optimization is purposed to cope with the particular environment of wireless media rather than generic one, it seems appropriate to extend basic xcap-el/attr MIME type by defining a new MIME type, *if allowed*, than trying to directly extend xcap-el/attr MIME type. > I think wireless industry should be worried about increased verbosity as well. So imo it is much better to have s simpler response format (only for GET method) including all in-scope namespaces in only, according to the canonical xml rules (not exclusive). The use case here is still blind updates after the retrieval of in-scope namespaces if I have understood correctly. When the client issues this kind of request, it knows that response will contain superfluous namespace declarations. Given that canonical xml is the baseline determining the equivalence of xcap resources (or documents), the client may remove superfluous namespace declarations if it tries to store a local copy as well (which may not be the case regarding an upcoming "blind" update). So I'm definitely not against of having this sort of an additional optional feature as long as the base XCAP semantics is kept where the body looks similar to what appears in the document. I'm only questioning the proposed format. In principle, this could be used with put as well, but one can already use local namespace declarations in the body (with elements, but not with qualified attributes). What I'm not thrilled about that XCAP servers should remove superfluous namespace declarations. Sure, one can say that if this extension is supported, the server must also remove the superfluous namespace declarations. IMO, if this is specified as an extension to the base XCAP spec, that's fine (doesn't break the base spec, i.e. harmless though not super useful in a generic case) br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 13 06:48:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8cCF-0002Oi-9h; Mon, 13 Feb 2006 06:48:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8cCD-0002Od-N9 for simple@megatron.ietf.org; Mon, 13 Feb 2006 06:48:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11824 for ; Mon, 13 Feb 2006 06:47:00 -0500 (EST) Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8cPl-0005FW-8o for simple@ietf.org; Mon, 13 Feb 2006 07:02:46 -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 k1DBmYo2011645 for ; Mon, 13 Feb 2006 13:48:37 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 13:48:33 +0200 Received: from [127.0.0.1] ([172.21.35.139]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 13 Feb 2006 13:48:33 +0200 Message-ID: <43F07211.9040107@nokia.com> Date: Mon, 13 Feb 2006 13:48:33 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'simple@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2006 11:48:33.0055 (UTC) FILETIME=[6A6DE2F0:01C63093] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Niemi Aki Subject: [Simple] MSRP chat: draft-niemi-simple-chat-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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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. Until the document is published, you can fetch a copy from: http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-04.txt http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-04.html Comments are welcome. BR, 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 Feb 13 07:39:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8czd-00085c-Nb; Mon, 13 Feb 2006 07:39:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F79Sq-0005Tv-RR for simple@megatron.ietf.org; Thu, 09 Feb 2006 05:55:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08934 for ; Thu, 9 Feb 2006 05:54:04 -0500 (EST) Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F79fW-0002H6-EA for simple@ietf.org; Thu, 09 Feb 2006 06:09:00 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id BA77626C081; Thu, 9 Feb 2006 11:55:43 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 7DA5926C0F6; Thu, 9 Feb 2006 11:55:42 +0100 (CET) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 7467658F24D; Thu, 9 Feb 2006 11:55:42 +0100 (CET) Received: by batilda.nic.fr (Postfix, from userid 1000) id 5E9E816A9F2; Thu, 9 Feb 2006 11:55:42 +0100 (CET) Date: Thu, 9 Feb 2006 11:55:42 +0100 From: ext Stephane Bortzmeyer To: Jari Urpalainen Message-ID: <20060209105542.GA27122@nic.fr> References: <20060206220115.GA201@preston.sources.org> <43E9F8A5.6030805@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43E9F8A5.6030805@nokia.com> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-Mailman-Approved-At: Mon, 13 Feb 2006 07:39:46 -0500 Cc: Stephane Bortzmeyer , simple@ietf.org Subject: [Simple] Re: draft-xml-patch and the comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Wed, Feb 08, 2006 at 03:56:53PM +0200, Jari Urpalainen wrote a message of 112 lines which said: > So you say XPath, c14n etc. are evil, bad xml ;-). I've reread the Xpath specifiation and, while there is a comment() test, it does not clearly say that comments MUST be processed (the XML specification clearly says that it is not mandatory). And you say that XSLT is bad :-) because XSLT treat comments as... comments, not as information items like you do in your draft. This one will be added as a comment in the output. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 13 07:39:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8cze-00086A-Bc; Mon, 13 Feb 2006 07:39:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7EKV-0002b3-SS for simple@megatron.ietf.org; Thu, 09 Feb 2006 11:07:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04846 for ; Thu, 9 Feb 2006 11:05:47 -0500 (EST) Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7EXE-0005MY-6m for simple@ietf.org; Thu, 09 Feb 2006 11:20:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 609BB26C0C0; Thu, 9 Feb 2006 17:07:21 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 116C426C081; Thu, 9 Feb 2006 17:07:20 +0100 (CET) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 0D65C58ED67; Thu, 9 Feb 2006 17:07:20 +0100 (CET) Received: by batilda.nic.fr (Postfix, from userid 1000) id EF74C16A9F2; Thu, 9 Feb 2006 17:07:19 +0100 (CET) Date: Thu, 9 Feb 2006 17:07:19 +0100 From: ext Stephane Bortzmeyer To: Jari Urpalainen Message-ID: <20060209160719.GA21998@nic.fr> References: <20060206220115.GA201@preston.sources.org> <43E9F8A5.6030805@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43E9F8A5.6030805@nokia.com> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Mon, 13 Feb 2006 07:39:46 -0500 Cc: Stephane Bortzmeyer , simple@ietf.org Subject: [Simple] Re: draft-xml-patch and pos=append X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Wed, Feb 08, 2006 at 03:56:53PM +0200, Jari Urpalainen wrote a message of 112 lines which said: > >For consistency, I suggest adding a "append" option to the > >. It is the default, but, IMHO, it > >should be made explicit, for instance to allow patch authors to > >clearly state thay they want to append. > > > Well, I had this psvi like feature in the previous version, but this > is indeed a bad habit, one of those things that come from the w3c > schema language. Could you elaborate? I absolutely do not see the connection with the idiosyncrasies of the W3C Schema language. I was not suggesting to use the PSVI. I did not suggest to mess with the infoset. I suggested to add the "append" option and to let the application do the same thing for pos="append" and for no pos. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 13 09:13:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8eSE-0004qC-2p; Mon, 13 Feb 2006 09:13:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8eSA-0004mA-60 for simple@megatron.ietf.org; Mon, 13 Feb 2006 09:13:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22504 for ; Mon, 13 Feb 2006 09:11:35 -0500 (EST) From: Silvestr.Peknik@tietoenator.com Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8efi-0001N2-Lq for simple@ietf.org; Mon, 13 Feb 2006 09:27:27 -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: Mon, 13 Feb 2006 15:13:05 +0100 Message-ID: <3ACC9A25264A684F82C71840111F9798011E9392@carrera.eu.tieto.com> Thread-Topic: [Simple] problem with filters and resource lists Thread-Index: AcYuTLr/xOVhP0BmTbupAeDkI3T6cACR/fvg To: X-OriginalArrivalTime: 13 Feb 2006 14:13:07.0309 (UTC) FILETIME=[9CB001D0:01C630A7] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hello,=20 I found another thing I need help with.=20 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? 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. 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 Mon Feb 13 10:14:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fPT-0007QY-BU; Mon, 13 Feb 2006 10:14:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fPS-0007QT-HV for simple@megatron.ietf.org; Mon, 13 Feb 2006 10:14:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28987 for ; Mon, 13 Feb 2006 10:12:53 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8fcx-0003c2-G3 for simple@ietf.org; Mon, 13 Feb 2006 10:28:44 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 15668194467 for ; Mon, 13 Feb 2006 16:14:20 +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); Mon, 13 Feb 2006 16:12:56 +0100 In-Reply-To: <3ACC9A25264A684F82C71840111F9798011E9392@carrera.eu.tieto.com> References: <3ACC9A25264A684F82C71840111F9798011E9392@carrera.eu.tieto.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <55fdc7341b9a117b74031427f45a206d@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] problem with filters and resource lists Date: Mon, 13 Feb 2006 16:14:35 +0100 To: X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 13 Feb 2006 15:12:56.0774 (UTC) FILETIME=[F82CE660:01C630AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Feb 13, 2006, at 3:13 PM, wrote: > 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? Not quite. The text should be interpreted as saying that the individual resource specific filter is applied first. > > 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. Why is F2 being propagated? Hisham > 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 Mon Feb 13 10:24:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fYj-0003bL-Ed; Mon, 13 Feb 2006 10:24:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fYf-0003af-TG for simple@megatron.ietf.org; Mon, 13 Feb 2006 10:24:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00008 for ; Mon, 13 Feb 2006 10:22:25 -0500 (EST) From: Silvestr.Peknik@tietoenator.com Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8fmI-0003yR-6h for simple@ietf.org; Mon, 13 Feb 2006 10:38:15 -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: Mon, 13 Feb 2006 16:23:35 +0100 Message-ID: <3ACC9A25264A684F82C71840111F9798011E941C@carrera.eu.tieto.com> Thread-Topic: [Simple] problem with filters and resource lists Thread-Index: AcYwsDZqiUlKx4BySOqj/HePVKHZDAAACYEA To: X-OriginalArrivalTime: 13 Feb 2006 15:23:58.0271 (UTC) FILETIME=[827554F0:01C630B1] X-Spam-Score: 0.3 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Thanks for the information. See inline comments. -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Monday, February 13, 2006 4:15 PM To: Peknik Silvestr Cc: simple@ietf.org Subject: Re: [Simple] problem with filters and resource lists On Feb 13, 2006, at 3:13 PM, wrote: > 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=20 > 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? Not quite. The text should be interpreted as saying that the individual=20 resource specific filter is applied first. Silvestr: ok thanks, it is now clear to me. > > 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=20 > (F1) > and for list2 (F2). F2 is propagated to the subscription to list2. RLS2 > subscribes back to RLS1 to bob and propagates F2. Why is F2 being propagated? Hisham Silvestr: I guess you mean the second propagation - you're right it is my fault, F2 is not being propagated but anyway it is applied to bob because it applies to all resources in list2.=20 The result of is the same - bob is filtered by both F1 and F2. Is it correct? > 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 Mon Feb 13 11:08:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8gF8-0002iB-RF; Mon, 13 Feb 2006 11:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8gF7-0002h4-GA for simple@megatron.ietf.org; Mon, 13 Feb 2006 11:08:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03579 for ; Mon, 13 Feb 2006 11:06:16 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8gSj-0005Tm-9D for simple@ietf.org; Mon, 13 Feb 2006 11:22:07 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id ACB20194480 for ; Mon, 13 Feb 2006 17:07:49 +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); Mon, 13 Feb 2006 17:06:27 +0100 In-Reply-To: <3ACC9A25264A684F82C71840111F9798011E941C@carrera.eu.tieto.com> References: <3ACC9A25264A684F82C71840111F9798011E941C@carrera.eu.tieto.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <590cb530a34c25d1fb174d7d53a48534@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] problem with filters and resource lists Date: Mon, 13 Feb 2006 17:08:05 +0100 To: X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 13 Feb 2006 16:06:27.0480 (UTC) FILETIME=[71E7C180:01C630B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Feb 13, 2006, at 4:23 PM, wrote: > Thanks for the information. > > See inline comments. > > -----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 > > > On Feb 13, 2006, at 3:13 PM, wrote: > >> 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? > > Not quite. The text should be interpreted as saying that the individual > resource specific filter is applied first. > > Silvestr: ok thanks, it is now clear to me. > >> >> 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. > > Why is F2 being propagated? > > Hisham > > Silvestr: I guess you mean the second propagation - you're right it is > my fault, F2 is not being propagated but anyway it is applied to bob > because it applies to all resources in list2. > > The result of is the same - bob is filtered by both F1 and F2. Is it > correct? It is difficult for RLS1 to apply Bob's filter to the NOTIFY coming from RLS2 since the XML document in the NOTIFY is represented in mime type application/rlmi+xml. The draft however does say the following: " If the URI indicated by the filter is for one resource whose URI is under the RLS administrative control but is not part of the resource list that the subscription was addressed to, the filter is not propagated. In this case, it is the RLS responsibility to make sure than this filter is applied to notifications issued, if information about that resource is present." This means that RLS1 needs to make sure that F1 is *somehow* applied. ie. implementation specific. Hisham > >> 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 Mon Feb 13 20:45:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8pGK-0004yd-SB; Mon, 13 Feb 2006 20:45:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8pGH-0004yE-Ou for simple@megatron.ietf.org; Mon, 13 Feb 2006 20:45:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09968 for ; Mon, 13 Feb 2006 20:44:02 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8pU0-0005yS-8R for simple@ietf.org; Mon, 13 Feb 2006 21:00:00 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 13 Feb 2006 17:45:40 -0800 X-IronPort-AV: i="4.02,110,1139212800"; d="scan'208"; a="1776087132:sNHT30532614" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1E1jdQJ020490; Mon, 13 Feb 2006 17:45:39 -0800 (PST) Received: from 10.21.82.67 ([10.21.82.67]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Feb 2006 01:45:39 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 13 Feb 2006 16:25:12 -0800 Subject: Re: [Simple] 501 Not Implemented considered harmful in MSRP From: Cullen Jennings To: "Jussi K. Virtanen" , "simple@ietf.org" Message-ID: Thread-Topic: [Simple] 501 Not Implemented considered harmful in MSRP Thread-Index: AcYw/R5PXMa+tJzwEdqdmAARJEEJ/A== In-Reply-To: <43E4C929.7020907@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I guess I could go either way on this - I probably need to think about it more. More information about what went wrong is often better. On 2/4/06 7:32 AM, "Jussi K. Virtanen" wrote: > Hi, > > MSRP defines the status code 501 Not Implemented to be sent as a > response to a request with unknown request method. I propose that > the status code is removed and the status code 400 Bad Request is > used instead. > > The existence of 501 Not Implemented implies that it is acceptable > to introduce new capabilities (in this case, a new request method) > to a session outside an offer--answer exchange. As far as I can see, > this is in conflict with established conventions in SIP and SDP. > > > 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 From simple-bounces@ietf.org Mon Feb 13 20:45:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8pGM-0004z7-Tx; Mon, 13 Feb 2006 20:45:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8pGH-0004yF-Rj for simple@megatron.ietf.org; Mon, 13 Feb 2006 20:45:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09973 for ; Mon, 13 Feb 2006 20:44:03 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8pU0-0005yS-P9 for simple@ietf.org; Mon, 13 Feb 2006 21:00:01 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 13 Feb 2006 17:45:40 -0800 X-IronPort-AV: i="4.02,110,1139212800"; d="scan'208"; a="1776087137:sNHT30331842" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1E1jeQJ020498; Mon, 13 Feb 2006 17:45:40 -0800 (PST) Received: from 10.21.82.67 ([10.21.82.67]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Feb 2006 01:45:39 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 13 Feb 2006 16:28:46 -0800 Subject: Re: [Simple] Purpose of the namespace field in MSRP From: Cullen Jennings To: "Jussi K. Virtanen" , "simple@ietf.org" Message-ID: Thread-Topic: [Simple] Purpose of the namespace field in MSRP Thread-Index: AcYw/Z3c3D1Gj5zwEdqdmAARJEEJ/A== In-Reply-To: <43E4E30C.6070409@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org 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 From simple-bounces@ietf.org Mon Feb 13 20:45:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8pGP-000503-UM; Mon, 13 Feb 2006 20:45:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8pGJ-0004yT-PW for simple@megatron.ietf.org; Mon, 13 Feb 2006 20:45:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09979 for ; Mon, 13 Feb 2006 20:44:05 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8pU1-0005yV-MF for simple@ietf.org; Mon, 13 Feb 2006 21:00:03 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 13 Feb 2006 17:45:42 -0800 X-IronPort-AV: i="4.02,110,1139212800"; d="scan'208"; a="255293101:sNHT31352476" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1E1jeQJ020506; Mon, 13 Feb 2006 17:45:40 -0800 (PST) Received: from 10.21.82.67 ([10.21.82.67]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Feb 2006 01:45:40 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 13 Feb 2006 16:32:35 -0800 Subject: Re: [Simple] MSRP : Restricting of TCP Connection From: Cullen Jennings To: Eric Burger , Message-ID: Thread-Topic: [Simple] MSRP : Restricting of TCP Connection Thread-Index: AcYGBgPrETYUmKSRQz+ELFqm4k+FLQGuTEAgCQ+8XKI= In-Reply-To: <330A23D8336C0346B5C1A5BB1966664701E464F8@ATLANTIS.Brooktrout.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org If you use a relay, you only need a connection to your relay not to every person you send to. On 12/29/05 2:50 PM, "Burger, Eric" wrote: > Is the assertion that one packet every 30 or so minutes uses too much > bandwidth? If so, you've got bigger problems then whether someone opens = a > long-lived, unused TCP connection. >=20 > ________________________________________ > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of > Amitkumar.Goel@infineon.com > Sent: Wednesday, December 21, 2005 3:11 AM > To: simple@ietf.org > Subject: [Simple] MSRP : Restricting of TCP Connection >=20 > I was trying to find out why MSRP draft is restricting to the TCP connect= ion > only?=20 > =A0 > There may be situations where use of UDP is good for the system(In resour= ce > point of view). > =A0 > Here I pointing one situation but there can so many > =A0 > Two employees of a company working on the same project but sitting at the > different location. They need to exchange=A0info all over the day. In=A0morni= ng > they start an IM session and exchange some info. They both know that they= =A0may > exchange messages/information some time latter also. Both of them will=A0av= oid > to=A0close the session.=A0 > This can happen to many employees of the company and=A0there can be lack of > resources due to use of TCP(like bandwidth etc).=A0 We can avoid this situa= tion > by using UDP connection. > =A0 > I know this is a pretty silly=A0question and it may also be =A0possible that = some > discussion was already taken place in past. Can anybody tell me where=A0I > can=A0find=A0out some text regarding this? > =A0 > Thanks in Advance!!!!!!!!! > Regards, > Amit Kumar Goel > Infineon Technology, > 11th Floor, Discoverer Building, > Whitefield,ITPL, > Bangalore-560066 > Ph: +91(080)41392721 > Mobile:9448948977 > =A0 >=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 Feb 14 07:33:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8zNO-0007Hi-BA; Tue, 14 Feb 2006 07:33:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8zNM-0007Hb-F6 for simple@megatron.ietf.org; Tue, 14 Feb 2006 07:33:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21024 for ; Tue, 14 Feb 2006 07:32:01 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8zbA-00084j-CQ for simple@ietf.org; Tue, 14 Feb 2006 07:48:05 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 48CFC194474 for ; Tue, 14 Feb 2006 13:33:37 +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); Tue, 14 Feb 2006 13:32:14 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <10d140261181287f0d159869c7042de0@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] 501 Not Implemented considered harmful in MSRP Date: Tue, 14 Feb 2006 13:33:52 +0100 To: Cullen Jennings X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 14 Feb 2006 12:32:14.0136 (UTC) FILETIME=[AF20DB80:01C63162] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org You can extend MSRP with new methods. We however do not negotiate supported MSRP methods in the offer/answer exchange when initiating the request. Therefore 501 is needed. I don't understand why 400 is better in this case. The draft says "A 501 response indicates that the recipient does not understand the request method." Regards, Hisham On Feb 14, 2006, at 1:25 AM, Cullen Jennings wrote: > > I guess I could go either way on this - I probably need to think about > it > more. More information about what went wrong is often better. > > On 2/4/06 7:32 AM, "Jussi K. Virtanen" > wrote: > >> Hi, >> >> MSRP defines the status code 501 Not Implemented to be sent as a >> response to a request with unknown request method. I propose that >> the status code is removed and the status code 400 Bad Request is >> used instead. > >> >> The existence of 501 Not Implemented implies that it is acceptable >> to introduce new capabilities (in this case, a new request method) >> to a session outside an offer--answer exchange. As far as I can see, >> this is in conflict with established conventions in SIP and SDP. > > >> >> >> 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 Tue Feb 14 20:41:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9BfZ-0007I7-2B; Tue, 14 Feb 2006 20:41:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9BfR-0007D0-DA for simple@megatron.ietf.org; Tue, 14 Feb 2006 20:41:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24746 for ; Tue, 14 Feb 2006 20:39:30 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9BtL-0003um-4u for simple@ietf.org; Tue, 14 Feb 2006 20:55:41 -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 <0IUP008TVH19HB@szxga01-in.huawei.com> for simple@ietf.org; Wed, 15 Feb 2006 09:48:45 +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 <0IUP00KVBH19A8@szxga01-in.huawei.com> for simple@ietf.org; Wed, 15 Feb 2006 09:48:45 +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 <0IUP002ZWH4J1K@szxml02-in.huawei.com> for simple@ietf.org; Wed, 15 Feb 2006 09:50:51 +0800 (CST) Date: Wed, 15 Feb 2006 09:38:31 +0800 From: Xiao Wang Subject: [SIMPLE] Update I-D:A Method to deliver Resource Information List for Presence Information To: simple@ietf.org Message-id: <014601c631d0$8a03a0d0$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.3 (/) X-Scan-Signature: 00134749b78ab2213964fc53d03de937 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============0675242227==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0675242227== Content-type: multipart/alternative; boundary="Boundary_(ID_V9iSxYkGkf/vl2Hlmo3D4Q)" This is a multi-part message in MIME format. --Boundary_(ID_V9iSxYkGkf/vl2Hlmo3D4Q) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi, all A update ID about A Method to deliver Resource Information List for Presence Information in SIMPLE is available now. Please kindly give your comments. I'm really appreciation your comments. Best regards, Xiao ---------------------------------------------------------------------------- ----------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Method to deliver Resource Information List for Presence Information Author(s) : X. Wang, P. Xu Filename : draft-wang-simple-presence-ril-01.txt Pages : 23 Date : 2006-2-14 Presence Information Data Format(PIDF) [1] and Rich Presence Extensions to the Presence Information Data Format(RPID) [2] have definition for a lot of presence information. Notifier can filter the presence information to subscriber according to local policy . But the notifier may not support all the presence information. It is a matter how to inform the subscriber the allowed, forbidden and unsupported presence information. This document provides a method to solve this problem by introducing the concept of Resource Information List(RIL). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wang-simple-presence-ril-01.txt --Boundary_(ID_V9iSxYkGkf/vl2Hlmo3D4Q) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi, all

         A update ID about A Method to deliver Resource Information List for Presence Information

    in SIMPLE is available now.

 

    Please kindly give your comments. I'm really appreciation your comments.

 

Best regards,

 

Xiao

 

 ---------------------------------------------------------------------------------------------

A New Internet-Draft is available from the on-line Internet-Drafts directories.

 

 

         Title           : A Method to deliver Resource Information List for Presence Information

         Author(s)  : X. Wang, P. Xu

         Filename : draft-wang-simple-presence-ril-01.txt

         Pages                : 23

         Date          : 2006-2-14

        

Presence Information Data Format(PIDF) [1] and Rich Presence Extensions to the Presence Information Data Format(RPID) [2] have definition for a lot of presence information.  Notifier can filter the presence information to subscriber according to local policy . But the notifier may not support all the presence information.  It is a matter how to inform the subscriber the allowed, forbidden and unsupported presence information.  This document provides a method to solve this problem by introducing the concept of Resource Information List(RIL).

 

A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wang-simple-presence-ril-01.txt

 

   

--Boundary_(ID_V9iSxYkGkf/vl2Hlmo3D4Q)-- --===============0675242227== 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 --===============0675242227==-- From simple-bounces@ietf.org Tue Feb 14 22:24:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9DHJ-0005J7-E3; Tue, 14 Feb 2006 22:24:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9DHD-0005Hc-Cy for simple@megatron.ietf.org; Tue, 14 Feb 2006 22:24:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00887 for ; Tue, 14 Feb 2006 22:22:37 -0500 (EST) 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 1F9DV9-00078h-RJ for simple@ietf.org; Tue, 14 Feb 2006 22:38:48 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 14 Feb 2006 19:24:13 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1F3ODKT003071; Tue, 14 Feb 2006 19:24:13 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 19:24:13 -0800 Received: from [10.21.144.75] ([10.21.144.75]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 19:24:12 -0800 Message-ID: <43F29EDB.50400@cisco.com> Date: Tue, 14 Feb 2006 22:24:11 -0500 From: Paul Kyzivat 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> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Feb 2006 03:24:12.0934 (UTC) FILETIME=[4AD15A60:01C631DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a great improvement. My remaining comments are primarily about nicknames: - as you already comment, I think nicknames belong as a feature of conferences in general, not MSRP mixer sessions. In principle, I think the assignment of nicknames should be handled via the conference control protocol. (Whose accronym I currently forget.) As a result I am troubled by using MSRP as a protocol for doing this. (Should we also extend RTP to support assigning of nicknames?) The implications of doing this then cascade down to having new SDP to negotiate whether the MSRP peer is capable of assigning nicknames. - (minor editorial issue) I think you intend to permit other mechanisms to deal with nickname retention. There is some language to that effect. But there is also language that brings this into doubt: 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. This seems too strong about what a nickname *is*. I think it would be good to say that the server *may* issue nicknames scoped this way. But the user should be able to suggest any nickname that it believes the server may allow it to use, and the server may accept it. This would give much more latitude for future work. - The lifetime of the nickname is said to be the lifetime of the session. But it isn't clear if that is the MSRP session or the SIP session. (IMO it ought to be the SIP session.) One might retain the sip session and change the MSRP session. This really highlights whether the nickname is chat specific. That's all. Paul 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. > > Until the document is published, you can fetch a copy from: > http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-04.txt > http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-04.html > > Comments are welcome. > > BR, > > > Miguel > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 15 08:11:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9MRU-0006UZ-LW; Wed, 15 Feb 2006 08:11:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9MRS-0006T1-ET for simple@megatron.ietf.org; Wed, 15 Feb 2006 08:11:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07491 for ; Wed, 15 Feb 2006 08:09:47 -0500 (EST) From: Silvestr.Peknik@tietoenator.com Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9MfP-00013v-NG for simple@ietf.org; Wed, 15 Feb 2006 08:26:04 -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 Feb 2006 14:11:17 +0100 Message-ID: <3ACC9A25264A684F82C71840111F979801233841@carrera.eu.tieto.com> Thread-Topic: triggers in filter-format drafts selecting multiple elements - problem? Thread-Index: AcYyMU4LiG8a5lCvRxCJ+wfQgefNpw== To: X-OriginalArrivalTime: 15 Feb 2006 13:11:19.0302 (UTC) FILETIME=[4F5E8A60:01C63231] X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Subject: [Simple] triggers in filter-format drafts selecting multiple elements - problem? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hello, again a question about filtering. Draft-ietf-simple-filter-format-05 describes triggers defining conditions under which notifications are sent. Lets take the trigger: "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." ... It is also written that the elements can identify more than one element: " In some cases, due to the design of the XML schema, the XPATH-like expression results in identifying more than one element with the same name (the XPATH expression may not have uniquely identified an element at every step). In those cases, all elements identified are selected." What happens if I have trigger defining change from "open" to "closed" for some element, and the XPATH-like expression selects more than one element? One can be changed from "open" to "closed", the other from "closed" to "open. Similarly, if the selector in element selects one element in previous document and 2 elements in current document, is it a match? 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 Wed Feb 15 08:27:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Mgk-0004Jw-DS; Wed, 15 Feb 2006 08:27:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Mgi-0004JY-IA for simple@megatron.ietf.org; Wed, 15 Feb 2006 08:27:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08806 for ; Wed, 15 Feb 2006 08:25:33 -0500 (EST) From: Silvestr.Peknik@tietoenator.com Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Muj-0001fx-9s for simple@ietf.org; Wed, 15 Feb 2006 08:41:50 -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: Wed, 15 Feb 2006 14:26:34 +0100 Message-ID: <3ACC9A25264A684F82C71840111F979801233879@carrera.eu.tieto.com> Thread-Topic: [Simple] problem with filters and resource lists Thread-Index: AcYwt7UQt1VxuPXqS3im00OdbupdbwBe4CIQ To: X-OriginalArrivalTime: 15 Feb 2006 13:27:09.0677 (UTC) FILETIME=[85D641D0:01C63233] X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org As I understand it now the order of the filters will be different for following situations: - List1 at RLS1, List2 at RLS2 - F1 targeted to bob@1.com / bob@2.com respectively - F2 targeted to list2@2.com Situation 1: List1@1.com - list2@2.com List2@2.com - bob@1.com Order of filters applied to bob: F2 (propagated to RLS2), F1 (kept by RLS1) Situation 2: List1@1.com=20 - list2@2.com=20 List2@2.com=20 - bob@2.com=20 Order of filters applied to bob: F1, F2 The order is important because it can change the resulting notification, e.g. if F1 excludes all elements and F2 is triggered by change in element. So we would have different results for the same filters based on the distribution of the resources. Is this behavior intended (if the scenarios are correct)? Silvestr Peknik TietoEnator _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 15 09:13:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9NPF-0003oY-HF; Wed, 15 Feb 2006 09:13:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9NPC-0003n3-Ix for simple@megatron.ietf.org; Wed, 15 Feb 2006 09:13:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12472 for ; Wed, 15 Feb 2006 09:11:31 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9NdE-0003XG-MZ for simple@ietf.org; Wed, 15 Feb 2006 09:27: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 D03C8194473 for ; Wed, 15 Feb 2006 15:13:08 +0100 (CET) Received: from [192.168.1.58] ([192.168.1.58]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Feb 2006 15:11:54 +0100 In-Reply-To: <3ACC9A25264A684F82C71840111F979801233879@carrera.eu.tieto.com> References: <3ACC9A25264A684F82C71840111F979801233879@carrera.eu.tieto.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3ea661d429a81ef9962c35b7bd248f58@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] problem with filters and resource lists Date: Wed, 15 Feb 2006 15:13:25 +0100 To: X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 15 Feb 2006 14:11:54.0756 (UTC) FILETIME=[C644CC40:01C63239] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Feb 15, 2006, at 2:26 PM, wrote: > As I understand it now the order of the filters will be different for > following situations: > > - List1 at RLS1, List2 at RLS2 > - F1 targeted to bob@1.com / bob@2.com respectively > - F2 targeted to list2@2.com > > Situation 1: > List1@1.com > - list2@2.com > > List2@2.com > - bob@1.com > > Order of filters applied to bob: F2 (propagated to RLS2), F1 (kept by > RLS1) As I said, this part is implementation dependent. I would implement it in a way that RLS1 remembers that there will be subscription coming for bob@1.com from a subscription it forwarded to RLS2. It will then apply F1 to the NOTIFY it sends to RLS2. In any case, the subscriber needs to create the filters in a smart way that they don't conflict (like in the example you give below about ). > > Situation 2: > List1@1.com > - list2@2.com > > List2@2.com > - bob@2.com > > Order of filters applied to bob: F1, F2 This is correct. Hisham > > The order is important because it can change the resulting > notification, > e.g. if F1 excludes all elements and F2 is triggered by change > in element. So we would have different results for the same > filters based on the distribution of the resources. > > Is this behavior intended (if the scenarios are correct)? > > Silvestr Peknik > TietoEnator > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 15 09:24:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Na4-0006kJ-47; Wed, 15 Feb 2006 09:24:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Na2-0006je-Nx for simple@megatron.ietf.org; Wed, 15 Feb 2006 09:24:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13138 for ; Wed, 15 Feb 2006 09:22:42 -0500 (EST) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9No3-0003up-G0 for simple@ietf.org; Wed, 15 Feb 2006 09:39:01 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1FEOJEG017671; Wed, 15 Feb 2006 16:24:25 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Feb 2006 16:24:21 +0200 Received: from [127.0.0.1] ([172.21.35.139]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Feb 2006 16:24:20 +0200 Message-ID: <43F33995.7040604@nokia.com> Date: Wed, 15 Feb 2006 16:24:21 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] MSRP chat: draft-niemi-simple-chat-04.txt References: <43F07211.9040107@nokia.com> <43F29EDB.50400@cisco.com> In-Reply-To: <43F29EDB.50400@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Feb 2006 14:24:20.0795 (UTC) FILETIME=[82F150B0:01C6323B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Paul: Inline comments: Paul Kyzivat wrote: > This is a great improvement. My remaining comments are primarily about > nicknames: > > - as you already comment, I think nicknames belong as a feature of > conferences in general, not MSRP mixer sessions. In principle, I think > the assignment of nicknames should be handled via the conference control > protocol. (Whose accronym I currently forget.) As a result I am troubled > by using MSRP as a protocol for doing this. (Should we also extend RTP > to support assigning of nicknames?) The implications of doing this then > cascade down to having new SDP to negotiate whether the MSRP peer is > capable of assigning nicknames. The current idea is that nicknames are especially useful when you use them for providing privacy, but still be able to send "a communication" to the other party via the conference server. This is easy to fulfill with any Instant Messaging protocol, because if I the conference server anonymizes me, I can still send you an IM and you can reply back to me through my nickname, but you don't know my real SIP URI. I don't really know what is the use case for RTP, because if I send you audio or video you will identify me immediately, in spite the conference server is anonymizing me. So that has been the main driver for providing the function in MSRP. The other thing is that, existing systems (and IRC is an example of it) provide similar functionality. Yet another thing... I am not sure what will be the reaction of the SIP WG if we propose the standardization of the NICKNAME method... > > - (minor editorial issue) I think you intend to permit other mechanisms > to deal with nickname retention. There is some language to that effect. > But there is also language that brings this into doubt: > > 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. > > This seems too strong about what a nickname *is*. I think it would be > good to say that the server *may* issue nicknames scoped this way. But > the user should be able to suggest any nickname that it believes the > server may allow it to use, and the server may accept it. This would > give much more latitude for future work. OK, sounds a nice suggestion. > > - The lifetime of the nickname is said to be the lifetime of the > session. But it isn't clear if that is the MSRP session or the SIP > session. (IMO it ought to be the SIP session.) One might retain the sip > session and change the MSRP session. This really highlights whether the > nickname is chat specific. > This is a good point since, I always got in mind that the SIP session has an MSRP session... but I see the difference, so obviously that has to be clarified. And I see the point that this should be tied to the SIP session... Thanks, Miguel > That's all. > > Paul > > 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. >> >> Until the document is published, you can fetch a copy from: >> http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-04.txt >> http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-04.html >> >> Comments are welcome. >> >> BR, >> >> >> 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 Wed Feb 15 09:45:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Nu7-00064e-Ho; Wed, 15 Feb 2006 09:45:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Nu5-00064U-VL for simple@megatron.ietf.org; Wed, 15 Feb 2006 09:45:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14259 for ; Wed, 15 Feb 2006 09:43:26 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9O87-0004YY-Nt for simple@ietf.org; Wed, 15 Feb 2006 09:59:44 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 9A107194477 for ; Wed, 15 Feb 2006 15:45:02 +0100 (CET) Received: from [192.168.1.58] ([192.168.1.58]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Feb 2006 15:43:48 +0100 In-Reply-To: <3ACC9A25264A684F82C71840111F979801233841@carrera.eu.tieto.com> References: <3ACC9A25264A684F82C71840111F979801233841@carrera.eu.tieto.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0d4b337e93a3579d2c667565c54df921@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] triggers in filter-format drafts selecting multiple elements - problem? Date: Wed, 15 Feb 2006 15:45:18 +0100 To: Silvestr.Peknik@tietoenator.com X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 15 Feb 2006 14:43:48.0849 (UTC) FILETIME=[3B283610:01C6323E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Feb 15, 2006, at 2:11 PM, Silvestr.Peknik@tietoenator.com wrote: > Hello, again a question about filtering. > > Draft-ietf-simple-filter-format-05 describes triggers defining > conditions under which notifications are sent. Lets take the > trigger: > > "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." > ... > > It is also written that the elements can identify more than one > element: > > " In some cases, due to the design of the XML schema, the XPATH-like > expression results in identifying more than one element with the > same > name (the XPATH expression may not have uniquely identified an > element at every step). In those cases, all elements identified are > selected." > > What happens if I have trigger defining change from "open" to "closed" > for some element, and the XPATH-like expression selects more > than one element? One can be changed from "open" to "closed", the other > from "closed" to "open. There is only one element in a tuple, so I don't see how this would happen in this case. But I say if a trigger filter selects 2 elements, then its an error. > Similarly, if the selector in element > selects one element in previous document and 2 elements in current > document, is it a match? There is something wrong in the filter if one already existed. I doubt there will be examples where this would happen. 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 Wed Feb 15 11:51:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Ps3-0007P1-7K; Wed, 15 Feb 2006 11:51:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Ps0-0007O9-S6 for simple@megatron.ietf.org; Wed, 15 Feb 2006 11:51:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10227 for ; Wed, 15 Feb 2006 11:49:26 -0500 (EST) 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 1F9Q61-0006qW-QT for simple@ietf.org; Wed, 15 Feb 2006 12:05:44 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 15 Feb 2006 08:51:00 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1FGp0jv015753; Wed, 15 Feb 2006 08:51:00 -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); Wed, 15 Feb 2006 08:51:00 -0800 Received: from [10.21.147.14] ([10.21.147.14]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Feb 2006 08:50:59 -0800 Message-ID: <43F35BF2.20604@cisco.com> Date: Wed, 15 Feb 2006 11:50:58 -0500 From: Paul Kyzivat 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> <43F29EDB.50400@cisco.com> <43F33995.7040604@nokia.com> In-Reply-To: <43F33995.7040604@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Feb 2006 16:50:59.0735 (UTC) FILETIME=[FF850270:01C6324F] X-Spam-Score: 2.2 (++) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org more comments inline. Paul Miguel Garcia wrote: > Paul: > > Inline comments: > > Paul Kyzivat wrote: > >> This is a great improvement. My remaining comments are primarily about >> nicknames: >> >> - as you already comment, I think nicknames belong as a feature of >> conferences in general, not MSRP mixer sessions. In principle, I think >> the assignment of nicknames should be handled via the conference >> control protocol. (Whose accronym I currently forget.) As a result I >> am troubled by using MSRP as a protocol for doing this. (Should we >> also extend RTP to support assigning of nicknames?) The implications >> of doing this then cascade down to having new SDP to negotiate whether >> the MSRP peer is capable of assigning nicknames. > > > The current idea is that nicknames are especially useful when you use > them for providing privacy, but still be able to send "a communication" > to the other party via the conference server. This is easy to fulfill > with any Instant Messaging protocol, because if I the conference server > anonymizes me, I can still send you an IM and you can reply back to me > through my nickname, but you don't know my real SIP URI. > > I don't really know what is the use case for RTP, because if I send you > audio or video you will identify me immediately, in spite the conference > server is anonymizing me. The example of RTP was intended as a bit of a joke, but not entirely. My thinking is that these nicknames can be learned via the roster from the focus, independent of the particular media being used in the call. Once I know the identity of a particular participant, then the desire to target communications to that person can also be independent of the particular media. Also, the fact that my voice is recognizable does not eliminate the value of a nickname for voice. In most of the cases I am aware of, the participants most likely don't know one another outside the chat room and so would not be able to correlate the voice with a real identity. I don't seriously think that it would make sense to request a nickname via RTP. MSRP is somewhat more ammenable to doing that, but it doesn't seem any more appropriate. Getting the nickname from the focus makes more sense to me. That still requires some mechanism, for each medium, to indicate that the media should be sent to a particular set of nicknames. The most general mechanism for that is the sidebar, but I know you consider that too heavyweight for some purposes. Perhaps it is ok that some media have a way other than sidebars, but for others the sidebar is the only mechanism. > So that has been the main driver for providing the function in MSRP. The > other thing is that, existing systems (and IRC is an example of it) > provide similar functionality. > > Yet another thing... I am not sure what will be the reaction of the SIP > WG if we propose the standardization of the NICKNAME method... I don't think it belongs in SIP. I had CSCP in mind as a suitable place. Paul >> - (minor editorial issue) I think you intend to permit other >> mechanisms to deal with nickname retention. There is some language to >> that effect. But there is also language that brings this into doubt: >> >> 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. >> >> This seems too strong about what a nickname *is*. I think it would be >> good to say that the server *may* issue nicknames scoped this way. But >> the user should be able to suggest any nickname that it believes the >> server may allow it to use, and the server may accept it. This would >> give much more latitude for future work. > > > OK, sounds a nice suggestion. > >> >> - The lifetime of the nickname is said to be the lifetime of the >> session. But it isn't clear if that is the MSRP session or the SIP >> session. (IMO it ought to be the SIP session.) One might retain the >> sip session and change the MSRP session. This really highlights >> whether the nickname is chat specific. >> > > This is a good point since, I always got in mind that the SIP session > has an MSRP session... but I see the difference, so obviously that has > to be clarified. And I see the point that this should be tied to the SIP > session... > > > Thanks, > > Miguel > > >> That's all. >> >> Paul >> >> 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. >>> >>> Until the document is published, you can fetch a copy from: >>> http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-04.txt >>> http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-04.html >>> >>> Comments are welcome. >>> >>> BR, >>> >>> >>> Miguel >>> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 16 02:35:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9dfp-0005TT-PS; Thu, 16 Feb 2006 02:35:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9dev-0004Fp-Nd for simple@megatron.ietf.org; Thu, 16 Feb 2006 02:34:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25212 for ; Thu, 16 Feb 2006 02:32:50 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9dt4-0000IH-TE for simple@ietf.org; Thu, 16 Feb 2006 02:49:17 -0500 Received: by nproxy.gmail.com with SMTP id k27so61491nfc for ; Wed, 15 Feb 2006 23:34:33 -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=eHVQZKac5rO6szQ1pPlddsYUAn+dO+rpS8NfeCOXaoHPVE+iMB67841A7dRJYVmfkewEQXRbOHqiius/JrusA8Q0B4aAPADbmjixchs4C0FI0mjkImgFGH7ZtIWXdUjpxMtTF4Y6ZH8sSlHLrx0n8p9Kmq7MPIOXpY2xH3gCxk8= Received: by 10.48.244.12 with SMTP id r12mr112682nfh; Wed, 15 Feb 2006 23:34:33 -0800 (PST) Received: by 10.48.234.17 with HTTP; Wed, 15 Feb 2006 23:34:33 -0800 (PST) Message-ID: <95d59cef0602152334q617f1d1cocf183832038aec47@mail.gmail.com> Date: Thu, 16 Feb 2006 09:34:33 +0200 From: "Jussi K. Virtanen" To: Hisham Khartabil Subject: Re: [Simple] 501 Not Implemented considered harmful in MSRP In-Reply-To: <10d140261181287f0d159869c7042de0@telio.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <10d140261181287f0d159869c7042de0@telio.no> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, On 2006-02-14, Hisham Khartabil wrote: > You can extend MSRP with new methods. We however do not > negotiate supported MSRP methods in the offer/answer exchange > when initiating the request. Therefore 501 is needed. I don't > understand why 400 is better in this case. RFC 3261 "SIP: Session Initiation Protocol": "SIP supports five facets of establishing and terminating multimedia communications: -- -- User capabilities: determination of the media and media parameters to be used; -- -- Session management: including transfer and termination of sessions, modifying session parameters, and invoking services." Why should MSRP implement a lacklustre detour on something that is SIP's forte? In my opinion, MSRP should explicitly promote the negotiation of all extensions, some of which may introduce new request methods, via an offer--answer exchange, because the introduction of such an extension is a disruptive change---there's a chance that the other endpoint is unable to support it. Thus, the rationale behind my proposition to use the status code 400 for an unknown request method is to make it clear that it's unacceptable to bypass session control when making disruptive changes to a medium. BR, -- Jussi K. Virtanen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 16 03:18:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9eLW-0005hT-3p; Thu, 16 Feb 2006 03:18:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9eJQ-0004ji-2L for simple@megatron.ietf.org; Thu, 16 Feb 2006 03:16:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27712 for ; Thu, 16 Feb 2006 03:14:40 -0500 (EST) From: Silvestr.Peknik@tietoenator.com Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9eXX-0001Ve-BJ for simple@ietf.org; Thu, 16 Feb 2006 03:31:08 -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] triggers in filter-format drafts selecting multiple elements - problem? Date: Thu, 16 Feb 2006 09:15:02 +0100 Message-ID: <3ACC9A25264A684F82C71840111F979801233B15@carrera.eu.tieto.com> Thread-Topic: [Simple] triggers in filter-format drafts selecting multiple elements - problem? Thread-Index: AcYyPnDhqjIbkpKERN+vTUrzZqxu5AAjR6fw To: X-OriginalArrivalTime: 16 Feb 2006 08:15:26.0097 (UTC) FILETIME=[240C3010:01C632D1] X-Spam-Score: 0.3 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org >There is only one element in a tuple, so I don't see how this=20 >would happen in this case. But I say if a trigger filter selects 2=20 >elements, then its an error. I don't understand it now. In the draft is explicitly stated that the XPATH-like selector may select multiple elements and that all identified elements are selected. Example: //tuple/status/basic Before change: open sip:im@example.com closed sip:poc@example.com After change (note that also the order has changed): open sip:poc@example.com closed sip:im@example.com Filter selects:=20 open, closed before change open, closed after change How do we know which elements should we compare? Do we take into consideration the parent path to each element? That would bring another problem - are 2 equal elements selected by a wildcard-trigger equal if they have different parents? -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Wednesday, February 15, 2006 3:45 PM To: Peknik Silvestr Cc: simple@ietf.org Subject: Re: [Simple] triggers in filter-format drafts selecting multiple elements - problem? On Feb 15, 2006, at 2:11 PM, Silvestr.Peknik@tietoenator.com wrote: > Hello, again a question about filtering. > > Draft-ietf-simple-filter-format-05 describes triggers defining > conditions under which notifications are sent. Lets take the > trigger: > > "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=20 > activate > the trigger and cause the content to be delivered." > ... > > It is also written that the elements can identify more than one=20 > element: > > " In some cases, due to the design of the XML schema, the XPATH-like > expression results in identifying more than one element with the=20 > same > name (the XPATH expression may not have uniquely identified an > element at every step). In those cases, all elements identified are > selected." > > What happens if I have trigger defining change from "open" to "closed" > for some element, and the XPATH-like expression selects more > than one element? One can be changed from "open" to "closed", the other > from "closed" to "open. There is only one element in a tuple, so I don't see how this=20 would happen in this case. But I say if a trigger filter selects 2=20 elements, then its an error. > Similarly, if the selector in element > selects one element in previous document and 2 elements in current > document, is it a match? There is something wrong in the filter if one already existed. I doubt=20 there will be examples where this would happen. Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 16 04:01:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9f1D-0004o7-J3; Thu, 16 Feb 2006 04:01:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9f1C-0004o2-UM for simple@megatron.ietf.org; Thu, 16 Feb 2006 04:01:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00601 for ; Thu, 16 Feb 2006 03:59:54 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9fFI-0003C0-5M for simple@ietf.org; Thu, 16 Feb 2006 04:16:23 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 13F05194480 for ; Thu, 16 Feb 2006 10:01:26 +0100 (CET) Received: from [192.168.1.46] ([192.168.1.46]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Feb 2006 10:00:04 +0100 In-Reply-To: <3ACC9A25264A684F82C71840111F979801233B15@carrera.eu.tieto.com> References: <3ACC9A25264A684F82C71840111F979801233B15@carrera.eu.tieto.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <320215e7e02bcbc0976d7484abdbb061@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] triggers in filter-format drafts selecting multiple elements - problem? Date: Thu, 16 Feb 2006 10:01:42 +0100 To: X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 16 Feb 2006 09:00:04.0975 (UTC) FILETIME=[60C887F0:01C632D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org You should construct your filter to either look like //tuple[@id="1"]/status/basic or //tuple[@id="2"]/status/basic or both at the same time. It doesnt make sense to have a filter as you define it. Hisham On Feb 16, 2006, at 9:15 AM, wrote: >> There is only one element in a tuple, so I don't see how this >> would happen in this case. But I say if a trigger filter selects 2 >> elements, then its an error. > > I don't understand it now. In the draft is explicitly stated that the > XPATH-like selector may select multiple elements and that all > identified > elements are selected. > > Example: > //tuple/status/basic > > > Before change: > > > open > > sip:im@example.com > > > > closed > > sip:poc@example.com > > > After change (note that also the order has changed): > > > open > > sip:poc@example.com > > > > closed > > sip:im@example.com > > > Filter selects: > open, closed before change > open, closed after change > > How do we know which elements should we compare? Do we take into > consideration the parent path to each element? That would bring another > problem - are 2 equal elements selected by a wildcard-trigger > equal if they have different parents? > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Wednesday, February 15, 2006 3:45 PM > To: Peknik Silvestr > Cc: simple@ietf.org > Subject: Re: [Simple] triggers in filter-format drafts selecting > multiple elements - problem? > > > On Feb 15, 2006, at 2:11 PM, Silvestr.Peknik@tietoenator.com wrote: > >> Hello, again a question about filtering. >> >> Draft-ietf-simple-filter-format-05 describes triggers defining >> conditions under which notifications are sent. Lets take the >> trigger: >> >> "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." >> ... >> >> It is also written that the elements can identify more than one >> element: >> >> " In some cases, due to the design of the XML schema, the XPATH-like >> expression results in identifying more than one element with the >> same >> name (the XPATH expression may not have uniquely identified an >> element at every step). In those cases, all elements identified > are >> selected." >> >> What happens if I have trigger defining change from "open" to "closed" >> for some element, and the XPATH-like expression selects more >> than one element? One can be changed from "open" to "closed", the > other >> from "closed" to "open. > > There is only one element in a tuple, so I don't see how this > would happen in this case. But I say if a trigger filter selects 2 > elements, then its an error. > > >> Similarly, if the selector in element >> selects one element in previous document and 2 elements in current >> document, is it a match? > > There is something wrong in the filter if one already existed. I doubt > there will be examples where this would happen. > > Hisham > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 16 04:51:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9fmv-0001Pf-7W; Thu, 16 Feb 2006 04:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9fmt-0001NI-3U for simple@megatron.ietf.org; Thu, 16 Feb 2006 04:50:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04918 for ; Thu, 16 Feb 2006 04:49:10 -0500 (EST) From: Silvestr.Peknik@tietoenator.com Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9g12-0005Jr-LZ for simple@ietf.org; Thu, 16 Feb 2006 05:05:39 -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] triggers in filter-format drafts selecting multiple elements - problem? Date: Thu, 16 Feb 2006 10:50:42 +0100 Message-ID: <3ACC9A25264A684F82C71840111F979801233BFF@carrera.eu.tieto.com> Thread-Topic: [Simple] triggers in filter-format drafts selecting multiple elements - problem? Thread-Index: AcYy152zkXUhU7qYSl6WWqqQUYCL/AABbVNg To: X-OriginalArrivalTime: 16 Feb 2006 09:50:46.0293 (UTC) FILETIME=[758CD450:01C632DE] X-Spam-Score: 0.3 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I agree that the filter does not make much sense; however I need to know how to handle such situation because we cannot guarantee that such filter will not be created by client. My opinion is that all possible cases should be covered by the specification to avoid specific behavior based on particular implementation.=20 If the specification does not define this, I would choose a solution which would reject filters containing triggers selecting multiple elements. Would such solution be correct? I mean, would it not be conflict with the specification? -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Thursday, February 16, 2006 10:02 AM To: Peknik Silvestr Cc: simple@ietf.org Subject: Re: [Simple] triggers in filter-format drafts selecting multiple elements - problem? You should construct your filter to either look like //tuple[@id=3D"1"]/status/basic or //tuple[@id=3D"2"]/status/basic or both at the same time. It doesnt make sense to have a filter as you define it. Hisham On Feb 16, 2006, at 9:15 AM, wrote: >> There is only one element in a tuple, so I don't see how this >> would happen in this case. But I say if a trigger filter selects 2 >> elements, then its an error. > > I don't understand it now. In the draft is explicitly stated that the > XPATH-like selector may select multiple elements and that all=20 > identified > elements are selected. > > Example: > //tuple/status/basic > > > Before change: > > > open > > sip:im@example.com > > > > closed > > sip:poc@example.com > > > After change (note that also the order has changed): > > > open > > sip:poc@example.com > > > > closed > > sip:im@example.com > > > Filter selects: > open, closed before change > open, closed after change > > How do we know which elements should we compare? Do we take into > consideration the parent path to each element? That would bring another > problem - are 2 equal elements selected by a wildcard-trigger > equal if they have different parents? > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Wednesday, February 15, 2006 3:45 PM > To: Peknik Silvestr > Cc: simple@ietf.org > Subject: Re: [Simple] triggers in filter-format drafts selecting > multiple elements - problem? > > > On Feb 15, 2006, at 2:11 PM, Silvestr.Peknik@tietoenator.com wrote: > >> Hello, again a question about filtering. >> >> Draft-ietf-simple-filter-format-05 describes triggers defining >> conditions under which notifications are sent. Lets take the >> trigger: >> >> "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." >> ... >> >> It is also written that the elements can identify more than one >> element: >> >> " In some cases, due to the design of the XML schema, the XPATH-like >> expression results in identifying more than one element with the >> same >> name (the XPATH expression may not have uniquely identified an >> element at every step). In those cases, all elements identified > are >> selected." >> >> What happens if I have trigger defining change from "open" to "closed" >> for some element, and the XPATH-like expression selects more >> than one element? One can be changed from "open" to "closed", the > other >> from "closed" to "open. > > There is only one element in a tuple, so I don't see how this > would happen in this case. But I say if a trigger filter selects 2 > elements, then its an error. > > >> Similarly, if the selector in element >> selects one element in previous document and 2 elements in current >> document, is it a match? > > There is something wrong in the filter if one already existed. I doubt > there will be examples where this would happen. > > Hisham > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 16 05:04:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9g07-0006ny-Qk; Thu, 16 Feb 2006 05:04:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9g05-0006dl-Av for simple@megatron.ietf.org; Thu, 16 Feb 2006 05:04:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06237 for ; Thu, 16 Feb 2006 05:02:48 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9gEG-0005tC-JU for simple@ietf.org; Thu, 16 Feb 2006 05:19:17 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id D4FB1194483 for ; Thu, 16 Feb 2006 11:04:25 +0100 (CET) Received: from [192.168.1.46] ([192.168.1.46]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Feb 2006 11:03:05 +0100 In-Reply-To: <3ACC9A25264A684F82C71840111F979801233BFF@carrera.eu.tieto.com> References: <3ACC9A25264A684F82C71840111F979801233BFF@carrera.eu.tieto.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <91abc4e64413db4ccd53b9f29b9891be@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] triggers in filter-format drafts selecting multiple elements - problem? Date: Thu, 16 Feb 2006 11:04:42 +0100 To: X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 16 Feb 2006 10:03:05.0643 (UTC) FILETIME=[2E3CAFB0:01C632E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Feb 16, 2006, at 10:50 AM, wrote: > I agree that the filter does not make much sense; however I need to > know > how to handle such situation because we cannot guarantee that such > filter will not be created by client. My opinion is that all possible > cases should be covered by the specification to avoid specific behavior > based on particular implementation. We cannot think of every possible cases that could cause problems. > > If the specification does not define this, I would choose a solution > which would reject filters containing triggers selecting multiple > elements. Would such solution be correct? yes. > I mean, would it not be > conflict with the specification? No. The text that you quote talks about the element. Hisham > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Thursday, February 16, 2006 10:02 AM > To: Peknik Silvestr > Cc: simple@ietf.org > Subject: Re: [Simple] triggers in filter-format drafts selecting > multiple elements - problem? > > You should construct your filter to either look like > > //tuple[@id="1"]/status/basic > > > > or > > //tuple[@id="2"]/status/basic > > > or both at the same time. > > > It doesnt make sense to have a filter as you define it. > > Hisham > > On Feb 16, 2006, at 9:15 AM, wrote: > >>> There is only one element in a tuple, so I don't see how > this >>> would happen in this case. But I say if a trigger filter selects 2 >>> elements, then its an error. >> >> I don't understand it now. In the draft is explicitly stated that the >> XPATH-like selector may select multiple elements and that all >> identified >> elements are selected. >> >> Example: >> //tuple/status/basic >> >> >> Before change: >> >> >> open >> >> sip:im@example.com >> >> >> >> closed >> >> sip:poc@example.com >> >> >> After change (note that also the order has changed): >> >> >> open >> >> sip:poc@example.com >> >> >> >> closed >> >> sip:im@example.com >> >> >> Filter selects: >> open, closed before change >> open, closed after change >> >> How do we know which elements should we compare? Do we take into >> consideration the parent path to each element? That would bring > another >> problem - are 2 equal elements selected by a wildcard-trigger >> equal if they have different parents? >> >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Wednesday, February 15, 2006 3:45 PM >> To: Peknik Silvestr >> Cc: simple@ietf.org >> Subject: Re: [Simple] triggers in filter-format drafts selecting >> multiple elements - problem? >> >> >> On Feb 15, 2006, at 2:11 PM, Silvestr.Peknik@tietoenator.com wrote: >> >>> Hello, again a question about filtering. >>> >>> Draft-ietf-simple-filter-format-05 describes triggers defining >>> conditions under which notifications are sent. Lets take the > >>> trigger: >>> >>> "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." >>> ... >>> >>> It is also written that the elements can identify more than one >>> element: >>> >>> " In some cases, due to the design of the XML schema, the XPATH-like >>> expression results in identifying more than one element with the >>> same >>> name (the XPATH expression may not have uniquely identified an >>> element at every step). In those cases, all elements identified >> are >>> selected." >>> >>> What happens if I have trigger defining change from "open" to > "closed" >>> for some element, and the XPATH-like expression selects more >>> than one element? One can be changed from "open" to "closed", the >> other >>> from "closed" to "open. >> >> There is only one element in a tuple, so I don't see how this >> would happen in this case. But I say if a trigger filter selects 2 >> elements, then its an error. >> >> >>> Similarly, if the selector in element >>> selects one element in previous document and 2 elements in current >>> document, is it a match? >> >> There is something wrong in the filter if one already existed. I doubt >> there will be examples where this would happen. >> >> Hisham >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 17 09:43:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6pm-0007mQ-In; Fri, 17 Feb 2006 09:43:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6mR-0005rm-J4 for simple@megatron.ietf.org; Fri, 17 Feb 2006 09:40:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01107 for ; Fri, 17 Feb 2006 09:00:12 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA1V1-0005Sc-4q for simple@ietf.org; Fri, 17 Feb 2006 04:02:10 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AE0264F0006; Fri, 17 Feb 2006 09:47:02 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Feb 2006 09:47:02 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Feb 2006 09:47:02 +0100 Received: from [131.160.126.99] (rvi2-126-99.lmf.ericsson.se [131.160.126.99]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0B0A02403; Fri, 17 Feb 2006 10:47:02 +0200 (EET) Message-ID: <43F58D84.9010304@ericsson.com> Date: Fri, 17 Feb 2006 10:47:00 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Feb 2006 08:47:02.0379 (UTC) FILETIME=[B8BB9BB0:01C6339E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy Subject: [Simple] SDP direction attribute and MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, as far as I can tell, the MSRP spec does not discuss its interaction with the SDP direction attribute (sendonly, recvonly, sendrecv). Shouldn't it do it? Thanks, Gonzalo _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 17 17:19:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADwX-00019E-9U; Fri, 17 Feb 2006 17:19:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADwW-000197-Ds for simple@megatron.ietf.org; Fri, 17 Feb 2006 17:19:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19107 for ; Fri, 17 Feb 2006 17:17:23 -0500 (EST) Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAEAq-0005sq-VX for simple@ietf.org; Fri, 17 Feb 2006 17:34:12 -0500 Received: from [10.1.11.100] ([12.45.241.210]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k1HMIvmP077075 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 17 Feb 2006 16:18:58 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v746.2) References: <89DCC40B-96E1-44C1-AA04-51F9AFCFE585@estacado.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <96197026-5541-42E0-9D2D-90B8E6379982@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Fri, 17 Feb 2006 17:18:24 -0500 To: "simple@ietf.org list" X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (shaman.nostrum.com: 12.45.241.210 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Subject: [Simple] ietf-simple 00s X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The working group chairs have to pre-approve any new (version 00) working group item drafts that are going to be submitted near the -00 deadline. As far as I know, we don't expect any for SIMPLE this time. If you were planning one, please let us know today. (This doesn't apply to individual submission -00s). Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Feb 19 03:03:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAjXK-00065h-Ab; Sun, 19 Feb 2006 03:03:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAjXI-00065W-Vw for simple@ietf.org; Sun, 19 Feb 2006 03:03:16 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAjXF-0001OA-PX for simple@ietf.org; Sun, 19 Feb 2006 03:03:16 -0500 X-IronPort-AV: i="4.02,127,1139202000"; d="scan'208"; a="28573251:sNHT27527112" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 19 Feb 2006 03:03:14 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <330A23D8336C0346B5C1A5BB1966664702417F62@ATLANTIS.Brooktrout.com> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IMDN? Thread-Index: AcY1Ku9bQiSkaq/BQrarHN5iuel5lQ== From: "Burger, Eric" To: "Simple WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Simple] 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 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 From simple-bounces@ietf.org Mon Feb 20 08:38:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBBEx-00017x-1M; Mon, 20 Feb 2006 08:38:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBBEv-00017r-Af for simple@ietf.org; Mon, 20 Feb 2006 08:38:09 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBBEu-0007f5-Rt for simple@ietf.org; Mon, 20 Feb 2006 08:38:09 -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 k1KDc0fl008806; Mon, 20 Feb 2006 15:38:05 +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 Feb 2006 15:38:05 +0200 Received: from [172.21.36.202] ([172.21.36.202]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Feb 2006 15:38:04 +0200 Message-ID: <43F9C63C.8090406@nokia.com> Date: Mon, 20 Feb 2006 15:38:04 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ext Jussi K. Virtanen" Subject: Re: [Simple] 501 Not Implemented considered harmful in MSRP References: <10d140261181287f0d159869c7042de0@telio.no> <95d59cef0602152334q617f1d1cocf183832038aec47@mail.gmail.com> In-Reply-To: <95d59cef0602152334q617f1d1cocf183832038aec47@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Feb 2006 13:38:04.0520 (UTC) FILETIME=[E0381E80:01C63622] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Cullen Jennings , 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 ext Jussi K. Virtanen wrote: > Hi, > > On 2006-02-14, Hisham Khartabil wrote: > >>You can extend MSRP with new methods. We however do not >>negotiate supported MSRP methods in the offer/answer exchange >>when initiating the request. Therefore 501 is needed. I don't >>understand why 400 is better in this case. > > > RFC 3261 "SIP: Session Initiation Protocol": > > "SIP supports five facets of establishing and terminating > multimedia communications: > > -- -- > > User capabilities: determination of the media and media > parameters to be used; > > -- -- > > Session management: including transfer and termination > of sessions, modifying session parameters, and > invoking services." > > > Why should MSRP implement a lacklustre detour on something that > is SIP's forte? > > In my opinion, MSRP should explicitly promote the negotiation > of all extensions, some of which may introduce new request > methods, via an offer--answer exchange, because the introduction > of such an extension is a disruptive change---there's a chance > that the other endpoint is unable to support it. I don't agree; the protocols that SIP and SDP set up may have plenty of details that the endpoints work out once the session is already agreed. For example, comedia-tls doesn't need to specify cipher suites or compression algorithms for the TLS session, because the correct place for those is in the TLS handshake. > Thus, the rationale behind my proposition to use the status code > 400 for an unknown request method is to make it clear that it's > unacceptable to bypass session control when making disruptive > changes to a medium. I think 5xx will work just as well. I think what you might actually be asking for is a way to do specific negotiation of features up front, in MSRP. Something like a server HELLO message that lists the allowed/supported methods that could actually be a different set depending on the configuration of the state machine, e.g., pre AUTH vs. after. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 20 22:47:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBOUM-0005rv-SW; Mon, 20 Feb 2006 22:46:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBOUL-0005rq-Uj for simple@ietf.org; Mon, 20 Feb 2006 22:46:57 -0500 Received: from lhrga01-in.huawei.com ([57.66.76.5] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBOUK-0008Ok-LS for simple@ietf.org; Mon, 20 Feb 2006 22:46:57 -0500 Received: from huawei.com ([172.24.2.3]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV0003WJPCK7T@lhrga01-in.huawei.com> for simple@ietf.org; Tue, 21 Feb 2006 03:21:56 +0000 (GMT) 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 <0IV000JHMQJ3N3@szxga01-in.huawei.com> for simple@ietf.org; Tue, 21 Feb 2006 11:47: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 <0IV0009SAQG0N3@szxga01-in.huawei.com> for simple@ietf.org; Tue, 21 Feb 2006 11:47:27 +0800 (CST) Received: from m24697A ([10.164.10.18]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IV000DOLQKCB8@szxml02-in.huawei.com>; Tue, 21 Feb 2006 11:48:12 +0800 (CST) Date: Tue, 21 Feb 2006 11:35:48 +0800 From: Lunjian Mu Subject: Re: [Simple] IMDN? To: "Burger, Eric" , Simple WG Message-id: <008901c63697$e7edc9c0$120aa40a@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: <330A23D8336C0346B5C1A5BB1966664702417F62@ATLANTIS.Brooktrout.com> 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 Hi Burger, In OMA MWG IM will use the IMDN, I have some comments on it: 1.From the example, the imdn.Message-ID of request is not the response's, and the ID of request is the same as the original-message-id in xml of IMDN. By my understanding one request to one user only receives one response from the user, why not the response Message-ID is the same as the request's and whether the original-message-id is needed? 2.whether the IMDN should include the mechanism of timer to wait for the notification. 3. Generally question: why the IMDN is not named as IMRN(instant messaging readed notification)? Because delivery notification is known as the report of successful delivery to the UA. Best regards, Lunjian Mu ----- Original Message ----- From: "Burger, Eric" To: "Simple WG" Sent: Sunday, February 19, 2006 4:03 PM 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 Tue Feb 21 00:47:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBQMo-0000BF-LH; Tue, 21 Feb 2006 00:47:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBQMn-0000BA-KN for simple@ietf.org; Tue, 21 Feb 2006 00:47:17 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBQMm-0003a3-Ct for simple@ietf.org; Tue, 21 Feb 2006 00:47:17 -0500 X-IronPort-AV: i="4.02,133,1139202000"; d="scan'208"; a="28707456:sNHT42139224" 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 Subject: RE: [Simple] IMDN? Date: Tue, 21 Feb 2006 00:47:11 -0500 Message-ID: <330A23D8336C0346B5C1A5BB1966664702461D99@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] IMDN? Thread-Index: AcY2maYPaksNRaYDQWi40GUKCmozjAAD6lMg From: "Burger, Eric" To: "Lunjian Mu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Thanks for the feedback! For question 1: The IMDN, from the perspective of the IM network, is simply an IM. Thus it requires its own, unique message identifier. Thus we have a data element with the message identifier of the original message. This way the sender can determine the identity of the original message. For question 2: One of the differences between transport delivery (REPORT) and user disposition (IMDN) is that transport delivery occurs pretty much in real-time, with the exception of store-and-forward. We can impose timers on transport delivery, because we have an idea, by design, how long it should take for a message to deliver. Once we introduce store-and-forward, the best the protocol (i.e. MSRP) can do is let the sender know "the network" reliably has the message. At that point the IMDN mechanism can kick in. The problem is the user's disposition has absolutely no deterministic time-out. There are many, many situation where a disposition notice (IMDN) will correctly never come. Thus we can neither specify a retry interval (time-out) nor require the user agent server to issue an IMDN. For question 3: The "D" in IMDN is for Disposition, not Delivery. "Read" is one of the dispositions, but there are a host of other dispositions. Thank you SO much for reviewing the draft - I hope this starts a dialog on the open issues on the list! Regards, Eric -----Original Message----- From: Lunjian Mu [mailto:mulj@huawei.com]=20 Sent: Monday, February 20, 2006 10:36 PM To: Burger, Eric; Simple WG Subject: Re: [Simple] IMDN? Hi Burger, In OMA MWG IM will use the IMDN, I have some comments on it: 1.From the example, the imdn.Message-ID of request is not the response's, and the ID of request is the same as the original-message-id in xml of IMDN. By my understanding one request to one user only receives one response from the user, why not the response Message-ID is the same as the request's and whether the original-message-id is needed?=20 2.whether the IMDN should include the mechanism of timer to wait for the notification. 3. Generally question: why the IMDN is not named as IMRN(instant messaging readed notification)? Because delivery notification is known as the report of successful delivery to the UA. Best regards, =20 Lunjian Mu _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 21 01:57:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBRSN-0002Yx-Ir; Tue, 21 Feb 2006 01:57:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBRSM-0002Ys-U1 for simple@ietf.org; Tue, 21 Feb 2006 01:57:06 -0500 Received: from nproxy.gmail.com ([64.233.182.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBRSL-0005dx-Ko for simple@ietf.org; Tue, 21 Feb 2006 01:57:06 -0500 Received: by nproxy.gmail.com with SMTP id c2so691873nfe for ; Mon, 20 Feb 2006 22:57:03 -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=eCRlhZ53aUNOXpS+lRkwEif4M+llI7Pa1hUl7S0xUcZ/CPUl4oz68JIia0KeN/vt9m25FZ5fCb0QV0SEaHsArd7+ZYa6tFZCJVryeNUWJe/wtxYA7ZX0hGtbFx4muyhrZiVjG1scijjjp8B3RWInYNxpmxIRIslKQyMQ1dIhXsM= Received: by 10.49.33.10 with SMTP id l10mr1425094nfj; Mon, 20 Feb 2006 22:57:03 -0800 (PST) Received: by 10.48.234.17 with HTTP; Mon, 20 Feb 2006 22:57:03 -0800 (PST) Message-ID: <95d59cef0602202257v5eb7a14y7ef7fafc5e6e7359@mail.gmail.com> Date: Tue, 21 Feb 2006 08:57:03 +0200 From: "Jussi K. Virtanen" To: "Aki Niemi" Subject: Re: [Simple] 501 Not Implemented considered harmful in MSRP In-Reply-To: <43F9C63C.8090406@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <10d140261181287f0d159869c7042de0@telio.no> <95d59cef0602152334q617f1d1cocf183832038aec47@mail.gmail.com> <43F9C63C.8090406@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Cullen Jennings , 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-02-20, Aki Niemi wrote: > I don't agree; the protocols that SIP and SDP set up may have > plenty of details that the endpoints work out once the session > is already agreed. For example, comedia-tls doesn't need to > specify cipher suites or compression algorithms for the TLS > session, because the correct place for those is in the TLS > handshake. I have a few gripes with your example. First, TLS was not initially designed with multimedia sessions in mind, unlike MSRP. Secondly, the TLS handshake is somewhat analogous to the authentication procedure in msrp-relays: both protocol entities are aware of its coming. > I think 5xx will work just as well. I think what you might > actually be asking for is a way to do specific negotiation of > features up front, in MSRP. Something like a server HELLO > message that lists the allowed/supported methods that could > actually be a different set depending on the configuration of > the state machine, e.g., pre AUTH vs. after. Why to reinvent the wheel? Wouldn't such a negotiation belong to session control? It could be based on, for example, a=3Dmethods:FOO BAR or something similar in SDP for request methods (beyond SEND and REPORT) that an endpoint either accepts or intends to utilise during a session. 501 makes sense in HTTP and SIP: in those protocols, the initial point of contact between a client and a server is a request. In MSRP, however, the initial point of contact is the offer--answer exchange. As I have stated earlier, my belief is that after the negotiation the endpoints should have a definite agreement of each other's capabilities so that disruptive changes cannot occur unless session control, based on SIP and SDP, is involved. BR, -- Jussi K. Virtanen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 21 08:49:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBXtn-00071D-OP; Tue, 21 Feb 2006 08:49:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBXtl-00070x-VD for simple@ietf.org; Tue, 21 Feb 2006 08:49:49 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBXtl-0003CK-CU for simple@ietf.org; Tue, 21 Feb 2006 08:49:49 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1LDnjgD016011; Tue, 21 Feb 2006 15:49:46 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Feb 2006 15:49:36 +0200 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Feb 2006 15:49: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 Subject: RE: [Simple] Re: Other MIME type than xcap-el/attr Date: Tue, 21 Feb 2006 15:49:34 +0200 Message-ID: <3D581AAC3824744CBA321327B00529B901AC846F@trebe101.NOE.Nokia.com> In-Reply-To: <1139827525.26644.94.camel@hed034-145.research.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Re: Other MIME type than xcap-el/attr Thread-Index: AcYwi5CY0/BGhfrzQze3K+30dt2aJAGYJN5A From: To: , X-OriginalArrivalTime: 21 Feb 2006 13:49:36.0246 (UTC) FILETIME=[A6EEE160:01C636ED] X-Spam-Score: 0.2 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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 Hello, So from OMA PAG WG point of view we like to know what is statement of SIMPLE WG to=20 following question: Is OMA PAG are already allowed (with XCAP-08) to make and use=20 OMA extension MIME type for retrieving namespace binding information without breaking=20 XCAP or does it requires relaxation of usage of xcap-el/attr MIME Type in XCAP.=20 And if the latter one is the case, then I'd like to know whether this could be=20 possible in the next version of XCAP or near future. Thanks in advance! Br, Antti >-----Original Message----- >From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]=20 >On Behalf Of ext Jari Urpalainen >Sent: 13 February, 2006 12:45 >To: ext Jaekwon Oh >Cc: Simple WG >Subject: Re: [Simple] Re: Other MIME type than xcap-el/attr > >On Sun, 2006-02-12 at 22:55 +0900, ext Jaekwon Oh wrote: >> Hello, >>=20 >> Thank you for response and find my response inline. >>=20 >> BR, >> Jaekwon Oh >>=20 >> Global Stanadards & Research >> Samsung Electronics, Co. Ltd. >> TEL +82 31 279 5086 >> CP +82 16 9530 5086 >> FAX +82 31 279 5130 >> jaekwon.oh@samsung.com >>=20 >>=20 >> ----- Original Message ----- >> From: "Jonathan Rosenberg" >> To: "Jari Urpalainen" >> Cc: "Jaekwon Oh" ; "Simple WG"=20 >> >> Sent: Friday, February 10, 2006 9:36 PM >> Subject: Re: [Simple] Re: Other MIME type than xcap-el/attr >>=20 >>=20 >> > inline. >> >=20 >> > Jari Urpalainen wrote: >> >=20 >> >> Inline -- >> >>=20 >> >> On Wed, 2006-02-08 at 16:57 -0500, ext Jonathan Rosenberg wrote: >> >>=20 >> >>>The intent was that its not meant to be extended, and=20 >that nothing=20 >> >>>else would be used. Do you have a use case or need for=20 >something else? >> >>> >> >>>Thanks, >> >>>Jonathan R. >> >>> >>=20 >> For namespace binding information, it is understood that=20 >namespace node retrival as defined in xcap-08 is quite clean=20 >solution. However, as the operation of grabbing a wireless=20 >channel for a tranascation is delay-prone in wireless media,=20 >the intended use case is to optimize the number of transaction=20 >in getting the namespace binding infomration by allowing the=20 >fragment to contain local namespace binding within itself. The=20 >following is an example of such fragment body: >>=20 >> Content-Type: application/xxxxxx+xml >>=20 >> >> urn:ietf:params:xml:ns:rls-services >> urn:ietf:params:xml:ns:resource-lists >> http://example.com/foo >> >>=20 >> >> > xmlns:xxxx=3D"......(local namespace declaration=20 >or local redeclaration, if any)" > >> >> >> >> >> >> presence >> >> >> >>=20 >> In the above example, the will contain=20 >the local namespace binding informatin as identified by all=20 >namespace node operation of '.../namespace::* under the=20 >element targeted. This approach allow the local namespace=20 >binding information to be within the fragment itself. Also,=20 >this approach would separate the local namespace binding=20 >information from the fragment body targeted. Thus, it could=20 >avoid the document cluttering by superfuluous local namespace=20 >binding information in the fragment body and also keep intact,=20 >any local namespace declaration or reclaration on an element. >>=20 >> However, as this optimization is purposed to cope with the=20 >particular environment of wireless media rather than generic=20 >one, it seems appropriate to extend basic xcap-el/attr MIME=20 >type by defining a new MIME type, *if allowed*, than trying to=20 >directly extend xcap-el/attr MIME type. >>=20 >I think wireless industry should be worried about increased=20 >verbosity as well. So imo it is much better to have s simpler=20 >response format (only for GET method) including all in-scope=20 >namespaces in only, according to the canonical xml=20 >rules (not exclusive). The use case here is still blind=20 >updates after the retrieval of in-scope namespaces if I have=20 >understood correctly. When the client issues this kind of=20 >request, it knows that response will contain superfluous=20 >namespace declarations. >Given that canonical xml is the baseline determining the=20 >equivalence of xcap resources (or documents), the client may=20 >remove superfluous namespace declarations if it tries to store=20 >a local copy as well (which may not be the case regarding an=20 >upcoming "blind" update). So I'm definitely not against of=20 >having this sort of an additional optional feature as long as=20 >the base XCAP semantics is kept where the body looks similar=20 >to what appears in the document. I'm only questioning the=20 >proposed format. > >In principle, this could be used with put as well, but one can=20 >already use local namespace declarations in the body (with=20 >elements, but not with qualified attributes). What I'm not=20 >thrilled about that XCAP servers should remove superfluous=20 >namespace declarations. Sure, one can say that if this=20 >extension is supported, the server must also remove the=20 >superfluous namespace declarations. IMO, if this is specified=20 >as an extension to the base XCAP spec, that's fine (doesn't=20 >break the base spec, i.e. harmless though not super useful in=20 >a generic case) 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 Wed Feb 22 15:50:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0w7-00056E-Hk; Wed, 22 Feb 2006 15:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0vy-00050q-Ui; Wed, 22 Feb 2006 15:50:02 -0500 Received: from [156.154.16.129] (helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC0vy-00070X-7V; Wed, 22 Feb 2006 15: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 k1MKo1vP004490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Feb 2006 20:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FC0vx-0004Pq-Pv; Wed, 22 Feb 2006 15: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, 22 Feb 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-msrp-relays-07.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 : Relay Extensions for the Message Sessions Relay Protocol (MSRP) Author(s) : C. Jennings, et al. Filename : draft-ietf-simple-msrp-relays-07.txt Pages : 36 Date : 2006-2-22 Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a SIP (Session Initiation Protocol) session, whereas Session-mode messages are set up as part of a session using the SIP protocol. MSRP (Message Session Relay Protocol) is a protocol for near real-time, peer-to- peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-relays-07.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-msrp-relays-07.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-msrp-relays-07.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-2-22123637.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-msrp-relays-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-msrp-relays-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-22123637.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 Feb 23 11:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCJ3y-0006dP-LG; Thu, 23 Feb 2006 11:11:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCJ3x-0006dH-N5 for simple@ietf.org; Thu, 23 Feb 2006 11:11:29 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCJ3w-0003a9-Po for simple@ietf.org; Thu, 23 Feb 2006 11:11: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 AA22619447B for ; Thu, 23 Feb 2006 17:11:27 +0100 (CET) Received: from [192.168.1.45] ([192.168.1.45]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Feb 2006 17:10:00 +0100 In-Reply-To: <3ACC9A25264A684F82C71840111F9798012BD761@carrera.eu.tieto.com> References: <3ACC9A25264A684F82C71840111F9798012BD761@carrera.eu.tieto.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 Subject: Re: [Simple] triggers in filter-format drafts selecting multiple elements - problem? Date: Thu, 23 Feb 2006 17:11:46 +0100 To: X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 23 Feb 2006 16:10:00.0049 (UTC) FILETIME=[98BCB610:01C63893] X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 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 Feb 23, 2006, at 4:30 PM, wrote: > Hello, > > I've been thinking about the triggers for some time and there are still > some issues unclear to me. You wrote: > >>> There is only one element in a tuple, so I don't see how > this >>> would happen in this case. But I say if a trigger filter selects 2 >>> elements, then its an error. > > However I found following parts in the drafts which show that trigger > selecting 2 elements is not an error: > 1/ from draft-ietf-simple-filter-format-05: > > The element triggers content delivery when the XML element it > identifies has been added to the document being filtered (that is, > this instance of that element appears in the current document, but > not the previous document). It can be used, for example, to learn > of new services and/or capabilities subscribed to by the user, or > services and/or capabilities that the user has now allowed the > subscriber to see. > > According to this, the trigger in element may select multiple > elements if more than one tuple is added. This is all implementation issues. The draft cannot state every possible scenario that a filter can combine. The entity processing the filter needs to examine the filter content and reject it if it does not make sense and accept it if it does. The example: it doesnt matter if 1 or 2 or 10 elements were added, as long as they are added. > > 2/ Example from the draft-ietf-simple-event-filter-funct-05 (7.3.1): > > SUBSCRIBE ... > > > > > > > > > > /pidf:presence/pidf:tuple/pidf:status/pidf:basic > > > > > > > > The presence document: > > > xmlns:rpid="urn:ietf:params:ns:rpid-tuple" > entity="sip:presentity@example.com"> > > > closed > > im > im:presentity@example.com > > > > closed > > voice > tel:2224055555@example.com > > > > So the trigger selects 2 elements. Yes, this selects 2 elements since the filter does not specify which tuple. The entity handling the filter can decide if this is an error or just apply the filter to all tuples. Again, this is implementation issue. > In the example, the "im" tuple is > changed to "open" and the notification is sent: > > > xmlns:rpid="urn:example-com:ietf:params:ns:rpid-tuple" > entity="sip:presentity@example.com"> > > > open > > im > im:presentity@example.com > > > > closed > > voice > tel:2224055555@example.com > > > > My question: if the presentity did not change the "im" tuple, but added > completely new tuple with status=open, would the trigger be evaluated > as > match? No. The element and its ancestors need to have already existed earlier for this to match to be a match. Hisham > > > xmlns:rpid="urn:example-com:ietf:params:ns:rpid-tuple" > entity="sip:presentity@example.com"> > > > closed > > im > im:presentity@example.com > > > > closed > > voice > tel:2224055555@example.com > > > > open > > mms > tel:123@example.com > > > > Silvestr > >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Thursday, February 16, 2006 10:02 AM >> To: Peknik Silvestr >> Cc: simple@ietf.org >> Subject: Re: [Simple] triggers in filter-format drafts selecting >> multiple elements - problem? >> >> You should construct your filter to either look like >> >> //tuple[@id="1"]/status/basic >> >> >> >> or >> >> //tuple[@id="2"]/status/basic >> >> >> or both at the same time. >> >> >> It doesnt make sense to have a filter as you define it. >> >> Hisham >> >> On Feb 16, 2006, at 9:15 AM, wrote: >> >>>> There is only one element in a tuple, so I don't see how >> this >>>> would happen in this case. But I say if a trigger filter selects 2 >>>> elements, then its an error. >>> >>> I don't understand it now. In the draft is explicitly stated that the >>> XPATH-like selector may select multiple elements and that all >>> identified >>> elements are selected. >>> >>> Example: >>> //tuple/status/basic >>> >>> >>> Before change: >>> >>> >>> open >>> >>> sip:im@example.com >>> >>> >>> >>> closed >>> >>> sip:poc@example.com >>> >>> >>> After change (note that also the order has changed): >>> >>> >>> open >>> >>> sip:poc@example.com >>> >>> >>> >>> closed >>> >>> sip:im@example.com >>> >>> >>> Filter selects: >>> open, closed before change >>> open, closed after change >>> >>> How do we know which elements should we compare? Do we take into >>> consideration the parent path to each element? That would bring >> another >>> problem - are 2 equal elements selected by a wildcard-trigger >>> equal if they have different parents? >>> >>> -----Original Message----- >>> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >>> Sent: Wednesday, February 15, 2006 3:45 PM >>> To: Peknik Silvestr >>> Cc: simple@ietf.org >>> Subject: Re: [Simple] triggers in filter-format drafts selecting >>> multiple elements - problem? >>> >>> >>> On Feb 15, 2006, at 2:11 PM, Silvestr.Peknik@tietoenator.com wrote: >>> >>>> Hello, again a question about filtering. >>>> >>>> Draft-ietf-simple-filter-format-05 describes triggers defining >>>> conditions under which notifications are sent. Lets take the >> >>>> trigger: >>>> >>>> "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." >>>> ... >>>> >>>> It is also written that the elements can identify more than one >>>> element: >>>> >>>> " In some cases, due to the design of the XML schema, the > XPATH-like >>>> expression results in identifying more than one element with the >>>> same >>>> name (the XPATH expression may not have uniquely identified an >>>> element at every step). In those cases, all elements identified >>> are >>>> selected." >>>> >>>> What happens if I have trigger defining change from "open" to >> "closed" >>>> for some element, and the XPATH-like expression selects > more >>>> than one element? One can be changed from "open" to "closed", the >>> other >>>> from "closed" to "open. >>> >>> There is only one element in a tuple, so I don't see how > this >>> would happen in this case. But I say if a trigger filter selects 2 >>> elements, then its an error. >>> >>> >>>> Similarly, if the selector in element >>>> selects one element in previous document and 2 elements in current >>>> document, is it a match? >>> >>> There is something wrong in the filter if one already existed. I > doubt >>> there will be examples where this would happen. >>> >>> Hisham >>> >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 23 11:28:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCJKZ-00019l-St; Thu, 23 Feb 2006 11:28:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCJKY-00019W-E1 for simple@ietf.org; Thu, 23 Feb 2006 11:28:38 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCIdg-0002hJ-Kb for simple@ietf.org; Thu, 23 Feb 2006 10:44:20 -0500 Received: from ebb01.tietoenator.com ([193.12.180.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FCIQT-0001Ra-Kf for simple@ietf.org; Thu, 23 Feb 2006 10:30:42 -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] triggers in filter-format drafts selecting multiple elements - problem? Date: Thu, 23 Feb 2006 16:30:34 +0100 Message-ID: <3ACC9A25264A684F82C71840111F9798012BD761@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] triggers in filter-format drafts selecting multiple elements - problem? Thread-Index: AcYy4HzWdI41LhHmTSCf276ze/SWDQFps6Aw From: To: X-OriginalArrivalTime: 23 Feb 2006 15:30:36.0429 (UTC) FILETIME=[17E8EBD0:01C6388E] X-Spam-Score: -2.6 (--) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 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 I've been thinking about the triggers for some time and there are still some issues unclear to me. You wrote: >> There is only one element in a tuple, so I don't see how this >> would happen in this case. But I say if a trigger filter selects 2 >> elements, then its an error. However I found following parts in the drafts which show that trigger selecting 2 elements is not an error: 1/ from draft-ietf-simple-filter-format-05: The element triggers content delivery when the XML element it identifies has been added to the document being filtered (that is, this instance of that element appears in the current document, but not the previous document). It can be used, for example, to learn of new services and/or capabilities subscribed to by the user, or services and/or capabilities that the user has now allowed the subscriber to see. According to this, the trigger in element may select multiple elements if more than one tuple is added. =20 2/ Example from the draft-ietf-simple-event-filter-funct-05 (7.3.1): SUBSCRIBE ... /pidf:presence/pidf:tuple/pidf:status/pidf:basic The presence document: closed im im:presentity@example.com closed voice tel:2224055555@example.com So the trigger selects 2 elements. In the example, the "im" tuple is changed to "open" and the notification is sent: open im im:presentity@example.com closed voice tel:2224055555@example.com My question: if the presentity did not change the "im" tuple, but added completely new tuple with status=3Dopen, would the trigger be evaluated = as match? closed im im:presentity@example.com closed voice tel:2224055555@example.com open mms tel:123@example.com Silvestr > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Thursday, February 16, 2006 10:02 AM > To: Peknik Silvestr > Cc: simple@ietf.org > Subject: Re: [Simple] triggers in filter-format drafts selecting > multiple elements - problem? > > You should construct your filter to either look like > > //tuple[@id=3D"1"]/status/basic > > > > or > > //tuple[@id=3D"2"]/status/basic > > > or both at the same time. > > > It doesnt make sense to have a filter as you define it. > > Hisham > > On Feb 16, 2006, at 9:15 AM, wrote: > >>> There is only one element in a tuple, so I don't see how > this >>> would happen in this case. But I say if a trigger filter selects 2 >>> elements, then its an error. >> >> I don't understand it now. In the draft is explicitly stated that the >> XPATH-like selector may select multiple elements and that all >> identified >> elements are selected. >> >> Example: >> //tuple/status/basic >> >> >> Before change: >> >> >> open >> >> sip:im@example.com >> >> >> >> closed >> >> sip:poc@example.com >> >> >> After change (note that also the order has changed): >> >> >> open >> >> sip:poc@example.com >> >> >> >> closed >> >> sip:im@example.com >> >> >> Filter selects: >> open, closed before change >> open, closed after change >> >> How do we know which elements should we compare? Do we take into >> consideration the parent path to each element? That would bring > another >> problem - are 2 equal elements selected by a wildcard-trigger >> equal if they have different parents? >> >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Wednesday, February 15, 2006 3:45 PM >> To: Peknik Silvestr >> Cc: simple@ietf.org >> Subject: Re: [Simple] triggers in filter-format drafts selecting >> multiple elements - problem? >> >> >> On Feb 15, 2006, at 2:11 PM, Silvestr.Peknik@tietoenator.com wrote: >> >>> Hello, again a question about filtering. >>> >>> Draft-ietf-simple-filter-format-05 describes triggers defining >>> conditions under which notifications are sent. Lets take the > >>> trigger: >>> >>> "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." >>> ... >>> >>> It is also written that the elements can identify more than one >>> element: >>> >>> " In some cases, due to the design of the XML schema, the XPATH-like >>> expression results in identifying more than one element with the >>> same >>> name (the XPATH expression may not have uniquely identified an >>> element at every step). In those cases, all elements identified >> are >>> selected." >>> >>> What happens if I have trigger defining change from "open" to > "closed" >>> for some element, and the XPATH-like expression selects more >>> than one element? One can be changed from "open" to "closed", the >> other >>> from "closed" to "open. >> >> There is only one element in a tuple, so I don't see how this >> would happen in this case. But I say if a trigger filter selects 2 >> elements, then its an error. >> >> >>> Similarly, if the selector in element >>> selects one element in previous document and 2 elements in current >>> document, is it a match? >> >> There is something wrong in the filter if one already existed. I doubt >> there will be examples where this would happen. >> >> Hisham >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 23 15:37:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCNDP-0002h8-Ot; Thu, 23 Feb 2006 15:37:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCNDP-0002fm-1j for simple@ietf.org; Thu, 23 Feb 2006 15:37:31 -0500 Received: from zproxy.gmail.com ([64.233.162.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCNDN-0003rU-R6 for simple@ietf.org; Thu, 23 Feb 2006 15:37:31 -0500 Received: by zproxy.gmail.com with SMTP id i11so149894nzh for ; Thu, 23 Feb 2006 12:37:29 -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=pM7gQQRJrBvkT+wZCGZbiXjl2RaUDz1/Ar+pPoQLg9vi5iw3aAbHsPygSqETycliNxLb8Wr8vX6CGpTBskAQkTZEooap1wfICnirYFCBlWfu7igP55u6TXQZCRuf798oT61UvDBgeMvZBc34IOJjxJPP/Y3b9lvMR+EBGFYPp1I= Received: by 10.65.239.3 with SMTP id q3mr666859qbr; Thu, 23 Feb 2006 12:37:29 -0800 (PST) Received: by 10.65.115.16 with HTTP; Thu, 23 Feb 2006 12:37:29 -0800 (PST) Message-ID: Date: Thu, 23 Feb 2006 15:37:29 -0500 From: "Arjun Roychowdhury" To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [Simple] XCAP Etag constraint with HTTP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============1857068574==" Errors-To: simple-bounces@ietf.org --===============1857068574== Content-Type: multipart/alternative; boundary="----=_Part_2628_25353859.1140727049315" ------=_Part_2628_25353859.1140727049315 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, Suppose I am using HTTP with XCAP to pass along auth. policies HTTP does not mandate that requests have If-Match, however, in my case, I want to accept the PUT only if it had If-Match So a) on receving a perfectly formed PUT without If-Match, can I return a 412 or is that return code only possible if the PUT had If-Match in the first place. If a) is not a possible solution: b) 11.1 of xcap-08 allows me to respond to PUT with where 'uniqueness constraint' is an application defined criteria. Can I return a 409 error with in the xcap-error body = ? regds arjun -- Arjun Roychowdhury ------=_Part_2628_25353859.1140727049315 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi,
Suppose I am using HTTP with XCAP to pass along auth. policies
 
HTTP does not mandate that requests have If-Match, however, in my case= , I want to accept the PUT only if it had If-Match
 
So
 
a) on receving a perfectly formed PUT without If-Match, can I return a= 412 or is that return code only possible if the PUT had If-Match in the fi= rst place.
If a) is not a possible solution:
 
b)
11.1 of xcap-08 allows me to respond to PUT with <uniqueness-failur= e> where 'uniqueness constraint' is an application defined criteria.
Can I return a 409  error with <uniqueness-failure> in the = xcap-error body ?
 
regds
arjun
 
 
--
Arjun Roychowdhury
 
------=_Part_2628_25353859.1140727049315-- --===============1857068574== 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 --===============1857068574==-- From simple-bounces@ietf.org Thu Feb 23 17:00:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCOVo-0002Rp-RR; Thu, 23 Feb 2006 17:00:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCOVn-0002Op-G5 for simple@ietf.org; Thu, 23 Feb 2006 17:00:35 -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 1FCOVn-00074j-4S for simple@ietf.org; Thu, 23 Feb 2006 17:00:35 -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 k1NLVLlb074253 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 23 Feb 2006 15:32:51 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: <95d59cef0602202257v5eb7a14y7ef7fafc5e6e7359@mail.gmail.com> References: <10d140261181287f0d159869c7042de0@telio.no> <95d59cef0602152334q617f1d1cocf183832038aec47@mail.gmail.com> <43F9C63C.8090406@nokia.com> <95d59cef0602202257v5eb7a14y7ef7fafc5e6e7359@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v749) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <87C8420D-5169-4872-9EB8-2502825D3062@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] 501 Not Implemented considered harmful in MSRP Date: Thu, 23 Feb 2006 15:31:14 -0600 To: "Jussi K. Virtanen" X-Mailer: Apple Mail (2.749) X-Spam-Score: 1.1 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Cullen Jennings , Aki Niemi , 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, I don't have a new argument to add to this either way. However, the idea of having explicit extension negotiation for MSRP has been considered on several occasions by the wg. What we have now was a result of that consensus, with the caveat that if someone introduces a new extension that requires more explicit negotiation, then that someone would also need to specify a way to signal or negotiate that extension; assumedly at the SDP level. Thanks! Ben. On Feb 21, 2006, at 12:57 AM, Jussi K. Virtanen wrote: > Hi, > > On 2006-02-20, Aki Niemi wrote: >> I don't agree; the protocols that SIP and SDP set up may have >> plenty of details that the endpoints work out once the session >> is already agreed. For example, comedia-tls doesn't need to >> specify cipher suites or compression algorithms for the TLS >> session, because the correct place for those is in the TLS >> handshake. > > I have a few gripes with your example. First, TLS was not > initially designed with multimedia sessions in mind, unlike MSRP. > Secondly, the TLS handshake is somewhat analogous to the > authentication procedure in msrp-relays: both protocol entities > are aware of its coming. > > >> I think 5xx will work just as well. I think what you might >> actually be asking for is a way to do specific negotiation of >> features up front, in MSRP. Something like a server HELLO >> message that lists the allowed/supported methods that could >> actually be a different set depending on the configuration of >> the state machine, e.g., pre AUTH vs. after. > > Why to reinvent the wheel? Wouldn't such a negotiation belong to > session control? It could be based on, for example, > > a=methods:FOO BAR > > or something similar in SDP for request methods (beyond SEND and > REPORT) that an endpoint either accepts or intends to utilise > during a session. > > 501 makes sense in HTTP and SIP: in those protocols, the initial > point of contact between a client and a server is a request. In > MSRP, however, the initial point of contact is the offer--answer > exchange. As I have stated earlier, my belief is that after the > negotiation the endpoints should have a definite agreement of > each other's capabilities so that disruptive changes cannot > occur unless session control, based on SIP and SDP, is involved. > > > BR, > > -- > 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 From simple-bounces@ietf.org Thu Feb 23 17:21:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCOps-000167-Ta; Thu, 23 Feb 2006 17:21:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCOpr-000162-Rq for simple@ietf.org; Thu, 23 Feb 2006 17:21:19 -0500 Received: from zproxy.gmail.com ([64.233.162.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCOpq-0007em-KT for simple@ietf.org; Thu, 23 Feb 2006 17:21:19 -0500 Received: by zproxy.gmail.com with SMTP id z6so191302nzd for ; Thu, 23 Feb 2006 14:21:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=RwvgL1CwdNOcWsix+4GHw/jti67wi+LRxsTY+Y9foHhLIKaItgJRBUB0hFDHvqI81OXKqI2DFUDsrWhd17KxFmQqIws7sYZkUqNY033oeYlqJCbimHoMdj8EHJ69R99Di7/oveOlZWy+deJ4KR1WjyTSXKgLHaoZx04HiJ/5UYw= Received: by 10.65.59.16 with SMTP id m16mr3319999qbk; Thu, 23 Feb 2006 14:21:17 -0800 (PST) Received: by 10.65.115.16 with HTTP; Thu, 23 Feb 2006 14:21:17 -0800 (PST) Message-ID: Date: Thu, 23 Feb 2006 17:21:17 -0500 From: "Arjun Roychowdhury" To: simple@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: [Simple] Re: XCAP Etag constraint with HTTP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============0622084139==" Errors-To: simple-bounces@ietf.org --===============0622084139== Content-Type: multipart/alternative; boundary="----=_Part_3948_7975708.1140733277218" ------=_Part_3948_7975708.1140733277218 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sorry, please replace with regds arjun On 2/23/06, Arjun Roychowdhury wrote: > > Hi, > Suppose I am using HTTP with XCAP to pass along auth. policies > > HTTP does not mandate that requests have If-Match, however, in my case, I > want to accept the PUT only if it had If-Match > > So > > a) on receving a perfectly formed PUT without If-Match, can I return a 41= 2 > or is that return code only possible if the PUT had If-Match in the first > place. > If a) is not a possible solution: > > b) > 11.1 of xcap-08 allows me to respond to PUT with > where 'uniqueness constraint' is an application defined criteria. > Can I return a 409 error with in the xcap-error bod= y > ? > > regds > arjun > > > -- > Arjun Roychowdhury > > -- Arjun Roychowdhury ------=_Part_3948_7975708.1140733277218 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Sorry, please replace <uniqueness-failure> with <constraint-f= ailure>
regds
arjun


 
On 2/23/06, = Arjun Roychowdhury <arjunrc@gma= il.com> wrote:
Hi,
Suppose I am using HTTP with XCAP to pass along auth. policies
 
HTTP does not mandate that requests have If-Match, however, in my case= , I want to accept the PUT only if it had If-Match
 
So
 
a) on receving a perfectly formed PUT without If-Match, can I return a= 412 or is that return code only possible if the PUT had If-Match in the fi= rst place.
If a) is not a possible solution:
 
b)
11.1 of xcap-08 allows me to respond to PUT with <uniqueness-failur= e> where 'uniqueness constraint' is an application defined criteria.
Can I return a 409  error with <uniqueness-failure> in the = xcap-error body ?
 
regds
arjun
 
 
--
Arjun Roychowdhury
 



--
Arjun Roychowdhury
------=_Part_3948_7975708.1140733277218-- --===============0622084139== 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 --===============0622084139==-- From simple-bounces@ietf.org Fri Feb 24 03:05:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCXx5-0003qs-Dg; Fri, 24 Feb 2006 03:05:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCXx4-0003qn-5T for Simple@ietf.org; Fri, 24 Feb 2006 03:05:22 -0500 Received: from nproxy.gmail.com ([64.233.182.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCXx2-0001JX-TY for Simple@ietf.org; Fri, 24 Feb 2006 03:05:22 -0500 Received: by nproxy.gmail.com with SMTP id p48so168682nfa for ; Fri, 24 Feb 2006 00:05:19 -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=lBTPbRVMpk8imLcxXlq1OP0YDsBqeOFscV+gPsLvV2jAT5/4uC1JlhGeGyigD74O+8Sl0bMNpiKNokT7GhrzlbKH9bS8U42zom7K394NY76i+lhaJi0zn/CgO5d4jgUs8tJll0GDHp0QxyVZM7eDP0vjM5frcJFWKOkdnNGme6o= Received: by 10.48.243.18 with SMTP id q18mr2683410nfh; Fri, 24 Feb 2006 00:05:19 -0800 (PST) Received: by 10.49.35.18 with HTTP; Fri, 24 Feb 2006 00:05:19 -0800 (PST) Message-ID: <52db68bc0602240005v2e26c395ud6832f0988cd73de@mail.gmail.com> Date: Fri, 24 Feb 2006 13:35:19 +0530 From: "Sudhir Kumar Reddy" To: Simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Simple] Query Regarding Polling in presence X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============1656290963==" Errors-To: simple-bounces@ietf.org --===============1656290963== Content-Type: multipart/alternative; boundary="----=_Part_13145_27148590.1140768319661" ------=_Part_13145_27148590.1140768319661 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi All, Is there any draft or RFC for "Reterieving the Presence through Polling"? any feedback is appericated. thanks in advance best regards Sudhir ------=_Part_13145_27148590.1140768319661 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi All,
 
Is there any draft or RFC for "Reterieving the Presence through P= olling"?
 
 
any feedback is appericated.
 
thanks in advance
 
best regards
Sudhir
 ------=_Part_13145_27148590.1140768319661-- --===============1656290963== 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 --===============1656290963==-- From simple-bounces@ietf.org Fri Feb 24 03:17:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCY8V-0003vf-D8; Fri, 24 Feb 2006 03:17:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCY8U-0003vI-AG for simple@ietf.org; Fri, 24 Feb 2006 03:17:10 -0500 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCY8T-0001gQ-FT for simple@ietf.org; Fri, 24 Feb 2006 03:17:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Feb 2006 09:14:26 +0100 Message-ID: <31721CD4D0090B4BA32CBA5E2C40AE9001D5CCF4@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Filtering - trigger evaluation Thread-Index: AcY5GlPqeootf0uXQuaSZ7BI+a+uOg== From: To: X-OriginalArrivalTime: 24 Feb 2006 08:14:29.0080 (UTC) FILETIME=[555E1580:01C6391A] X-Spam-Score: 0.2 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Subject: [Simple] Filtering - trigger evaluation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============0034824469==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0034824469== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6391A.54681EF5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6391A.54681EF5 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi everybody, =20 I'm working on some topics related to Event notification filtering and I = have reached an issue, which solution is not completely defined in = specification. Could someone answer me some questions? =20 The problem is as follows: 1. Client A subscribes to the presence document of client B. Client A = sends a filter with trigger in a body of the SUBSCRIBE request. 2. Client A receives notification. 3. Client B's presence state changes, so the notification has to be = sent, but the filtering trigger blocks that notification, so nothing is = sent to client A. 4. Client B's presence state changes again... =20 Which "old" presence document has to be used together with the fresh one = in order to evaluate filtering triggers? Is it a notification body that = was produced (but has not been sent) in step 3? Or is it the last = notification that was really sent to client A (notification from step = 2)? =20 Thanks for any suggestions =20 =20 Best regards, =20 Michal Burda Software Specialist TietoEnator a.s. Czech Software Centre Direct: +420 599 096 020 Fax: +420 599 096 110 E-mail: michal.burda@tietoenator.com V=FDstavn=ED 292/13 CZ-709 16 Ostrava CZECH REPUBLIC =20 www.tieotoenator.com =20 =20 Please note: The information contained in this message may be legally = privileged and confidential and protected from disclosure. If the reader = of this message is not the intended recipient, you are hereby notified = that any unauthorised use, distribution or copying of this communication = is strictly prohibited. If you have received this communication in = error, please notify us immediately by replying to the message and = deleting it from your computer. Thank you. =20 ------_=_NextPart_001_01C6391A.54681EF5 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi everybody,

 

I'm working on some topics related to Event = notification filtering and I have reached an issue, which solution is not completely = defined in specification. Could someone answer me some = questions?

 

The problem is as = follows:

1. Client A subscribes to the presence document of = client B. Client A sends a filter with trigger in a body of the SUBSCRIBE = request.

2. Client A receives = notification.

3. Client B's presence state changes, so the = notification has to be sent, but the filtering trigger blocks that notification, so = nothing is sent to client A.

4. Client B's presence state changes = again...

 

Which "old" presence document has to be = used together with the fresh one in order to evaluate filtering triggers? Is = it a notification body that was produced (but has not been sent) in step 3? = Or is it the last notification that was really sent to client A (notification = from step 2)?

 

Thanks for any = suggestions

 

 

Best regards,

 

Michal = Burda

Software = Specialist

= TietoEnator a.s.

Czech Software = Centre

Direct: +420 599 = 096 020

Fax: +420 599 = 096 110

E-mail: michal.burda@tietoenator.com=
V=FDstavn=ED = 292/13

CZ-709 16 = Ostrava

CZECH = REPUBLIC

 =

www.tieotoenator.com=

 =

Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this = message is not the intended recipient, you are hereby notified that any = unauthorised use, distribution or copying of this communication is strictly prohibited. If = you have received this communication in error, please notify us immediately = by replying to the message and deleting it from your computer. Thank = you.

 

------_=_NextPart_001_01C6391A.54681EF5-- --===============0034824469== 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 --===============0034824469==-- From simple-bounces@ietf.org Fri Feb 24 06:46:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCbOV-0003jb-8G; Fri, 24 Feb 2006 06:45:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCbOT-0003jV-F1 for Simple@ietf.org; Fri, 24 Feb 2006 06:45:53 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCbOS-0008Of-0a for Simple@ietf.org; Fri, 24 Feb 2006 06:45:53 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id EA22919447E for ; Fri, 24 Feb 2006 12:45:50 +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); Fri, 24 Feb 2006 12:44:22 +0100 In-Reply-To: <52db68bc0602240005v2e26c395ud6832f0988cd73de@mail.gmail.com> References: <52db68bc0602240005v2e26c395ud6832f0988cd73de@mail.gmail.com> 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] Query Regarding Polling in presence Date: Fri, 24 Feb 2006 12:46:10 +0100 To: "Sudhir Kumar Reddy" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 24 Feb 2006 11:44:22.0795 (UTC) FILETIME=[A7CE7DB0:01C63937] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org SUBSCRIBE with Expires header field value of 0 should do the trick. Regards, Hisham On Feb 24, 2006, at 9:05 AM, Sudhir Kumar Reddy wrote: > Hi All, > =A0 > Is there any draft or RFC for "Reterieving the Presence through=20 > Polling"? > =A0 > =A0 > any feedback is appericated. > =A0 > thanks in advance > =A0 > best regards > > Sudhir > _______________________________________________ > 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 Feb 24 06:49:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCbRy-00074r-TK; Fri, 24 Feb 2006 06:49:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCbRy-000749-0O for simple@ietf.org; Fri, 24 Feb 2006 06:49:30 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCbRx-0008US-EH for simple@ietf.org; Fri, 24 Feb 2006 06: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 ACEDA19447F for ; Fri, 24 Feb 2006 12:49:28 +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); Fri, 24 Feb 2006 12:48:00 +0100 In-Reply-To: <31721CD4D0090B4BA32CBA5E2C40AE9001D5CCF4@carrera.eu.tieto.com> References: <31721CD4D0090B4BA32CBA5E2C40AE9001D5CCF4@carrera.eu.tieto.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <040499e4ac9d928dbd1b6d4a1cfe4fed@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Simple] Filtering - trigger evaluation Date: Fri, 24 Feb 2006 12:49:48 +0100 To: X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 24 Feb 2006 11:48:00.0461 (UTC) FILETIME=[298BAFD0:01C63938] 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 The filter was built according to what the subscriber has, so I would=20 say the last notification that was really sent to client A=20 (notification from step 2) is the one used. Hisham On Feb 24, 2006, at 9:14 AM, wrote: > > Hi everybody, > =A0 > I'm working on some topics related to Event notification filtering and=20= > I have reached an issue, which solution is not completely defined in=20= > specification. Could someone answer me some questions? > =A0 > The problem is as follows: > 1. Client A subscribes to the presence document of client B. Client A=20= > sends a filter with trigger in a body of the SUBSCRIBE request. > 2. Client A receives notification. > 3. Client B's presence state changes, so the notification has to be=20 > sent, but the filtering trigger blocks that notification, so nothing=20= > is sent to client A. > 4. Client B's presence state changes again... > =A0 > Which "old" presence document has to be used together with the fresh=20= > one in order to evaluate filtering triggers? Is it a notification body=20= > that was produced (but has not been sent) in step 3? Or is it the last=20= > notification that was really sent to client A (notification from step=20= > 2)? > =A0 > Thanks for any suggestions > =A0 > =A0 > Best regards, > =A0 > Michal Burda > Software Specialist > > TietoEnator a.s. > Czech Software Centre > Direct: +420 599 096 020 > Fax: +420 599 096 110 > E-mail: michal.burda@tietoenator.com > V=FDstavn=ED 292/13 > CZ-709=A016 Ostrava > CZECH REPUBLIC > =A0 > www.tieotoenator.com > =A0 > Please note: The information contained in this message may be legally=20= > privileged and confidential and protected from disclosure. If the=20 > reader of this message is not the intended recipient, you are hereby=20= > notified that any unauthorised use, distribution or copying of this=20 > communication is strictly prohibited. If you have received this=20 > communication in error, please notify us immediately by replying to=20 > the message and deleting it from your computer. Thank you. > =A0 > _______________________________________________ > 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 Feb 24 07:45:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCcJw-00084Z-21; Fri, 24 Feb 2006 07:45:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCcJv-00084R-09 for simple@ietf.org; Fri, 24 Feb 2006 07:45:15 -0500 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCcJu-00019z-Cg for simple@ietf.org; Fri, 24 Feb 2006 07:45: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="iso-8859-2" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Filtering - trigger evaluation Date: Fri, 24 Feb 2006 13:45:08 +0100 Message-ID: <31721CD4D0090B4BA32CBA5E2C40AE9001D5D048@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Filtering - trigger evaluation Thread-Index: AcY5OHmrMJOP4hDRRuyZD1Udi14efQABRx7Q From: To: X-OriginalArrivalTime: 24 Feb 2006 12:45:13.0570 (UTC) FILETIME=[27D68C20:01C63940] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 After a discussion, we have found the following use case. Could anyone = comment it? Is my understanding of that issue right? 1. Client A subscribes to the presence document of client B. Client A = sends a filter with such trigger in a body of the SUBSCRIBE request that = sends notify message iff some particular element E is changed from value = 10 to value 20. 2. An initial NOTIFY message is sent to the client A - the value of E is = 10. 3. The B's presence document changes its state so now E has got 20. = Notification is sent to client A. 4. The B's presence document changes again. E's value is now 10. Nothing = is sent to client A. 5. E's value changes back to 20. However, last notification sent to = client A contained element E with value 20, too, so no notification is = sent to client A. Moreover, notification is NEVER MORE sent... Could you please comment this? > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Friday, February 24, 2006 12:50 PM > To: Burda Michal > Cc: simple@ietf.org > Subject: Re: [Simple] Filtering - trigger evaluation >=20 > The filter was built according to what the subscriber has, so I would > say the last notification that was really sent to client A > (notification from step 2) is the one used. >=20 > Hisham >=20 > On Feb 24, 2006, at 9:14 AM, wrote: >=20 > > > > Hi everybody, > > > > I'm working on some topics related to Event notification filtering = and > > I have reached an issue, which solution is not completely defined in > > specification. Could someone answer me some questions? > > > > The problem is as follows: > > 1. Client A subscribes to the presence document of client B. Client = A > > sends a filter with trigger in a body of the SUBSCRIBE request. > > 2. Client A receives notification. > > 3. Client B's presence state changes, so the notification has to be > > sent, but the filtering trigger blocks that notification, so nothing > > is sent to client A. > > 4. Client B's presence state changes again... > > > > Which "old" presence document has to be used together with the fresh > > one in order to evaluate filtering triggers? Is it a notification = body > > that was produced (but has not been sent) in step 3? Or is it the = last > > notification that was really sent to client A (notification from = step > > 2)? > > > > Thanks for any suggestions > > > > > > Best regards, > > > > Michal Burda > > Software Specialist > > > > TietoEnator a.s. > > Czech Software Centre > > Direct: +420 599 096 020 > > Fax: +420 599 096 110 > > E-mail: michal.burda@tietoenator.com > > V=FDstavn=ED 292/13 > > CZ-709=A016 Ostrava > > CZECH REPUBLIC > > > > www.tieotoenator.com > > > > Please note: The information contained in this message may be = legally > > privileged and confidential and protected from disclosure. If the > > reader of this message is not the intended recipient, you are hereby > > notified that any unauthorised use, distribution or copying of this > > communication is strictly prohibited. If you have received this > > communication in error, please notify us immediately by replying to > > the message and deleting it from your computer. Thank you. > > > > _______________________________________________ > > 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 Feb 24 09:43:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCeAO-0006Mt-EB; Fri, 24 Feb 2006 09:43:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCeAN-0006Mf-BO for simple@ietf.org; Fri, 24 Feb 2006 09:43:31 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCeAK-0005EC-I8 for simple@ietf.org; Fri, 24 Feb 2006 09:43:31 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 4225019447E for ; Fri, 24 Feb 2006 15:43:27 +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); Fri, 24 Feb 2006 15:41:58 +0100 In-Reply-To: <31721CD4D0090B4BA32CBA5E2C40AE9001D5D048@carrera.eu.tieto.com> References: <31721CD4D0090B4BA32CBA5E2C40AE9001D5D048@carrera.eu.tieto.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <632641e49f79f2af695697e1e90f9e2c@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Simple] Filtering - trigger evaluation Date: Fri, 24 Feb 2006 15:43:46 +0100 To: X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 24 Feb 2006 14:41:59.0012 (UTC) FILETIME=[77682A40:01C63950] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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 Yes that is correct behaviour. The subscriber needs to update filters=20 if s/he wishes for new information to come. Hisham On Feb 24, 2006, at 1:45 PM, wrote: > After a discussion, we have found the following use case. Could anyone=20= > comment it? Is my understanding of that issue right? > > 1. Client A subscribes to the presence document of client B. Client A=20= > sends a filter with such trigger in a body of the SUBSCRIBE request=20 > that sends notify message iff some particular element E is changed=20 > from value 10 to value 20. > > 2. An initial NOTIFY message is sent to the client A - the value of E=20= > is 10. > > 3. The B's presence document changes its state so now E has got 20.=20 > Notification is sent to client A. > > 4. The B's presence document changes again. E's value is now 10.=20 > Nothing is sent to client A. > > 5. E's value changes back to 20. However, last notification sent to=20 > client A contained element E with value 20, too, so no notification is=20= > sent to client A. Moreover, notification is NEVER MORE sent... > > > Could you please comment this? > > > > >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Friday, February 24, 2006 12:50 PM >> To: Burda Michal >> Cc: simple@ietf.org >> Subject: Re: [Simple] Filtering - trigger evaluation >> >> The filter was built according to what the subscriber has, so I would >> say the last notification that was really sent to client A >> (notification from step 2) is the one used. >> >> Hisham >> >> On Feb 24, 2006, at 9:14 AM, wrote: >> >>> >>> Hi everybody, >>> >>> I'm working on some topics related to Event notification filtering=20= >>> and >>> I have reached an issue, which solution is not completely defined in >>> specification. Could someone answer me some questions? >>> >>> The problem is as follows: >>> 1. Client A subscribes to the presence document of client B. Client = A >>> sends a filter with trigger in a body of the SUBSCRIBE request. >>> 2. Client A receives notification. >>> 3. Client B's presence state changes, so the notification has to be >>> sent, but the filtering trigger blocks that notification, so nothing >>> is sent to client A. >>> 4. Client B's presence state changes again... >>> >>> Which "old" presence document has to be used together with the fresh >>> one in order to evaluate filtering triggers? Is it a notification=20 >>> body >>> that was produced (but has not been sent) in step 3? Or is it the=20 >>> last >>> notification that was really sent to client A (notification from = step >>> 2)? >>> >>> Thanks for any suggestions >>> >>> >>> Best regards, >>> >>> Michal Burda >>> Software Specialist >>> >>> TietoEnator a.s. >>> Czech Software Centre >>> Direct: +420 599 096 020 >>> Fax: +420 599 096 110 >>> E-mail: michal.burda@tietoenator.com >>> V=FDstavn=ED 292/13 >>> CZ-709=A016 Ostrava >>> CZECH REPUBLIC >>> >>> www.tieotoenator.com >>> >>> Please note: The information contained in this message may be = legally >>> privileged and confidential and protected from disclosure. If the >>> reader of this message is not the intended recipient, you are hereby >>> notified that any unauthorised use, distribution or copying of this >>> communication is strictly prohibited. If you have received this >>> communication in error, please notify us immediately by replying to >>> the message and deleting it from your computer. Thank you. >>> >>> _______________________________________________ >>> 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 Feb 24 16:59:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCkyB-0008SM-KC; Fri, 24 Feb 2006 16:59:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCky9-0008PW-S6 for simple@ietf.org; Fri, 24 Feb 2006 16:59:21 -0500 Received: from wproxy.gmail.com ([64.233.184.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCky8-0003MN-J9 for simple@ietf.org; Fri, 24 Feb 2006 16:59:21 -0500 Received: by wproxy.gmail.com with SMTP id i11so706304wra for ; Fri, 24 Feb 2006 13:59:20 -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=tK9sZA5yF4M71HL5gOT0hTe8chIiP8VxkPWsY+NWP3ee6FZ+lQAGtw4lDOmieuxZdxXZWgHD93t5pcv1pwxSLK5xqjW6Apif1hgV/cVMxlzTQHMBLlUMU/InQZs81Fh5LBCkFgCbu1QbbtlKXesIKBR7U79soyXjlfy6vUOxXUk= Received: by 10.65.225.13 with SMTP id c13mr3242945qbr; Fri, 24 Feb 2006 13:59:19 -0800 (PST) Received: by 10.65.115.16 with HTTP; Fri, 24 Feb 2006 13:59:19 -0800 (PST) Message-ID: Date: Fri, 24 Feb 2006 16:59:19 -0500 From: "Arjun Roychowdhury" To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Simple] Question on winfo X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============0456757655==" Errors-To: simple-bounces@ietf.org --===============0456757655== Content-Type: multipart/alternative; boundary="----=_Part_16467_28623168.1140818359752" ------=_Part_16467_28623168.1140818359752 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, RFC 3857 (winfo) does not specify any package parameter in its specifications. We have a proprietary event package defined, call it 'foo' 'foo' requires a mandatory package parameter, say X So when a person subscribes, the Event Header looks like this: Event:foo;X=3D123 Now, we need to provide this X=3D123 even if it is a winfo template for my event Therefore, is it legal to do this: Event:foo.winfo;X=3D123 thx arjun -- Arjun Roychowdhury ------=_Part_16467_28623168.1140818359752 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi,
RFC 3857 (winfo) does not specify any package parameter in its specifi= cations.
 
We have a proprietary event package defined, call it 'foo'
 
'foo' requires a mandatory package parameter, say X
 
So when a person subscribes, the Event Header looks like this:
Event:foo;X=3D123
 
Now, we need to provide this X=3D123 even if it is a winfo template fo= r my event
 
Therefore, is it legal to do this:
 
Event:foo.winfo;X=3D123
 
thx
arjun

--
Arjun Roychowdhury
 
------=_Part_16467_28623168.1140818359752-- --===============0456757655== 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 --===============0456757655==-- From simple-bounces@ietf.org Fri Feb 24 17:54:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FClpj-0005Tq-UF; Fri, 24 Feb 2006 17:54:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FClpi-0005Te-O0 for simple@ietf.org; Fri, 24 Feb 2006 17:54:42 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FClph-0004zY-Fa for simple@ietf.org; Fri, 24 Feb 2006 17:54:42 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 24 Feb 2006 17:54:42 -0500 X-IronPort-AV: i="4.02,144,1139202000"; d="scan'208"; a="83089499:sNHT32227824" 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 k1OMsbqS003571; Fri, 24 Feb 2006 17:54:41 -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); Fri, 24 Feb 2006 17:54:40 -0500 Received: from [192.168.1.104] ([10.86.242.250]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Feb 2006 17:54:38 -0500 Message-ID: <43FF8EAE.8030204@cisco.com> Date: Fri, 24 Feb 2006 17:54:38 -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: Arjun Roychowdhury Subject: Re: [Simple] Question on winfo References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2006 22:54:38.0821 (UTC) FILETIME=[4A6D1150:01C63995] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 No, event package parameters are not inherited by winfo. -Jonathan R. Arjun Roychowdhury wrote: > Hi, > RFC 3857 (winfo) does not specify any package parameter in its > specifications. > > We have a proprietary event package defined, call it 'foo' > > 'foo' requires a mandatory package parameter, say X > > So when a person subscribes, the Event Header looks like this: > Event:foo;X=123 > > Now, we need to provide this X=123 even if it is a winfo template for my > event > > Therefore, is it legal to do this: > > Event:foo.winfo;X=123 > > thx > arjun > > -- > Arjun Roychowdhury > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Fri Feb 24 18:36:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCmUG-0000f3-Iv; Fri, 24 Feb 2006 18:36:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCmUF-0000eM-Fw for simple@ietf.org; Fri, 24 Feb 2006 18:36:35 -0500 Received: from zproxy.gmail.com ([64.233.162.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCmUE-0006a4-3X for simple@ietf.org; Fri, 24 Feb 2006 18:36:35 -0500 Received: by zproxy.gmail.com with SMTP id s18so439973nze for ; Fri, 24 Feb 2006 15:36:33 -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=Uijbv3DQa1qyWBhfnsGKP9SpdR9j55magiYxwODo+G0SgwgwFGFx73kBDYkJsm4RYxnZ3ZX1PvoJst7mQsYz2wJMpfKmLGlF/3sgE5krV4SQyzg0pjKbjReZkFTTh7PwftMZotSTteVPCT2MjVpacIaQd3TCaZHq938dn8QlWv8= Received: by 10.65.211.18 with SMTP id n18mr1586190qbq; Fri, 24 Feb 2006 15:36:32 -0800 (PST) Received: by 10.65.115.16 with HTTP; Fri, 24 Feb 2006 15:36:32 -0800 (PST) Message-ID: Date: Fri, 24 Feb 2006 18:36:32 -0500 From: "Arjun Roychowdhury" To: "Jonathan Rosenberg" Subject: Re: [Simple] Question on winfo In-Reply-To: <43FF8EAE.8030204@cisco.com> MIME-Version: 1.0 References: <43FF8EAE.8030204@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 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="===============0270067078==" Errors-To: simple-bounces@ietf.org --===============0270067078== Content-Type: multipart/alternative; boundary="----=_Part_17384_29702045.1140824192924" ------=_Part_17384_29702045.1140824192924 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thanks, I feared so :-) Since 3265 says "Event package parameters" can modify the behaviour of an event package, it can be expected that the parameters are a critical part o= f further sub-classification of a particular event, in which case, it would also be useful if winfo allowed any package parameters to pass along as well. Consider an example: An event package X allows each user to maintain several 'event objects' (therefore here, there is a n:1 relationship between the number of 'items' that a single user bob@example.com can PUBLISH to the Event Server. Each 'item' is therefore uniquely differentiable, as a further subclassification to bob@example.com Now, if Bob, wants to know if any other user subscribed to one of his items= , it would useful if he could just do: Event:X.winfo;item=3Ditem-id Anyway, since 3265 allows us to create our own events, and winfo is define= d to provide a ready template-event for subscribing to the state of another event , the Event Server which specified the package parameter in the first place is going to be responsible for the winfo handling as well and can interpret the item parameter, which can be passed on 'blindly' to the 'X handler' in the Event Server. regds arjun On 2/24/06, Jonathan Rosenberg wrote: > > No, event package parameters are not inherited by winfo. > > -Jonathan R. > > Arjun Roychowdhury wrote: > > > Hi, > > RFC 3857 (winfo) does not specify any package parameter in its > > specifications. > > > > We have a proprietary event package defined, call it 'foo' > > > > 'foo' requires a mandatory package parameter, say X > > > > So when a person subscribes, the Event Header looks like this: > > Event:foo;X=3D123 > > > > Now, we need to provide this X=3D123 even if it is a winfo template for= my > > event > > > > Therefore, is it legal to do this: > > > > Event:foo.winfo;X=3D123 > > > > thx > > arjun > > > > -- > > Arjun Roychowdhury > > > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > 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 > -- Arjun Roychowdhury ------=_Part_17384_29702045.1140824192924 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Thanks, I feared so :-)
 
Since 3265 says "Event package parameters" can modify the be= haviour of an event package, it can be expected that the parameters are a c= ritical part of further sub-classification of a particular event, in which = case, it would also be useful if winfo allowed any package parameters to pa= ss along as well.
 
Consider an example:
 
An event package X allows each user to maintain several 'event objects= ' (therefore here, there is a n:1 relationship between the number of 'items= ' that a single user bob@example.com can PUBLISH to the Event Server. Each 'item' is therefore uniquely differe= ntiable, as a further subclassification to bob@example.com
 
 
Now, if Bob, wants to know if any other user subscribed to one of his = items, it would useful if he could just do:
 
Event:X.winfo;item=3Ditem-id
 
Anyway, since 3265 allows us to  create our own events, and winfo= is defined to provide a ready template-event for subscribing to the state = of another event , the Event Server which specified the package parameter i= n the first place is going to be responsible for the winfo handling as well= and can interpret the item parameter, which can be passed on 'blindly' to = the 'X handler' in the Event Server.
 
regds
arjun


 
On 2/24/06, = Jonathan Rosenberg <jdrosen@cis= co.com> wrote:
No, event package parameters are= not inherited by winfo.

-Jonathan R.

Arjun Roychowdhury wrot= e:

> Hi,
> RFC 3857 (winfo) does not specify any package para= meter in its
> specifications.
>
> We have a proprietary = event package defined, call it 'foo'
>
> 'foo' requires a manda= tory package parameter, say X
>
> So when a person subscribes, the Event Header looks like t= his:
> Event:foo;X=3D123
>
> Now, we need to provide this= X=3D123 even if it is a winfo template for my
> event
>
>= ; Therefore, is it legal to do this:
>
> Event:foo.winfo;X=3D123
>
> thx
> arjun<= br>>
> --
> Arjun Roychowdhury
>
>
>
&g= t; ------------------------------------------------------------------------
>
> _______________________________________________
> Si= mple mailing list
> Simple@ietf.or= g
> htt= ps://www1.ietf.org/mailman/listinfo/simple

--
Jonathan D. Rosenberg, Ph.D.     = ;            &n= bsp; 600 Lanidex Plaza
Cisco Fellow      &= nbsp;           &nbs= p;            &= nbsp;   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com             = ;            &n= bsp;     FAX:   (973) 952-5050
http://www.jdrosen.net   &n= bsp;            = ;         PHONE: (973) 952-5000
= http://www.cisco.com



--
Arjun Roychowdhury<= br> ------=_Part_17384_29702045.1140824192924-- --===============0270067078== 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 --===============0270067078==-- From simple-bounces@ietf.org Mon Feb 27 00:04:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDaYd-0002M5-SO; Mon, 27 Feb 2006 00:04:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDaYc-0002LL-5R for simple@ietf.org; Mon, 27 Feb 2006 00:04:26 -0500 Received: from mail.cis.nctu.edu.tw ([140.113.23.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDaYb-0002xD-KS for simple@ietf.org; Mon, 27 Feb 2006 00:04:26 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.cis.nctu.edu.tw (8.13.4/8.13.4) with ESMTP id k1R54OIX074508 for ; Mon, 27 Feb 2006 13:04:24 +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 73990-02 for ; Mon, 27 Feb 2006 13:04:24 +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 k1R54NaI074497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Feb 2006 13:04:24 +0800 (CST) (envelope-from icq.cis92@gmail.com) Message-ID: <4402885A.4010706@gmail.com> Date: Mon, 27 Feb 2006 13:04:26 +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 MESSAGE 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: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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, 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 From simple-bounces@ietf.org Mon Feb 27 00:11:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDafr-0005za-4v; Mon, 27 Feb 2006 00:11:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDafo-0005zV-Ts for simple@ietf.org; Mon, 27 Feb 2006 00:11:52 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDafl-000398-8o for simple@ietf.org; Mon, 27 Feb 2006 00:11:52 -0500 Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IVB00M57YEDZD@mailout2.samsung.com> for simple@ietf.org; Mon, 27 Feb 2006 14:11:01 +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 <0IVB00875YECKU@mmp2.samsung.com> for simple@ietf.org; Mon, 27 Feb 2006 14:11:01 +0900 (KST) Date: Mon, 27 Feb 2006 14:09:47 +0900 From: "jp.yi" Subject: RE: [Simple]Question on MESSAGE In-reply-to: <4402885A.4010706@gmail.com> To: 'Ren-Huang Liou' , simple@ietf.org Message-id: <001401c63b5c$07c970f0$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=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Yes.. You don't need to use INVITE message for MESSAGE session. BEST, JP. -----Original Message----- From: Ren-Huang Liou [mailto:icq.cis92@gmail.com] Sent: Monday, February 27, 2006 2:04 PM To: simple@ietf.org Subject: [Simple]Question on MESSAGE 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 From simple-bounces@ietf.org Mon Feb 27 00:39:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDb66-0007Kn-LQ; Mon, 27 Feb 2006 00:39:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDb65-0007Ki-BY for simple@ietf.org; Mon, 27 Feb 2006 00:39:01 -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 1FDb64-0003mQ-1k for simple@ietf.org; Mon, 27 Feb 2006 00:39:01 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 26 Feb 2006 21:38:59 -0800 X-IronPort-AV: i="4.02,149,1139212800"; d="scan'208"; a="410148631:sNHT30292552" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1R5cxHf027206; Sun, 26 Feb 2006 21:38:59 -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); Mon, 27 Feb 2006 00:38:58 -0500 Received: from [10.82.240.97] ([10.82.240.97]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Feb 2006 00:38:58 -0500 Message-ID: <44029071.3080507@cisco.com> Date: Mon, 27 Feb 2006 00:38:57 -0500 From: Michael Zhou User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Ren-Huang Liou Subject: Re: [Simple]Question on MESSAGE References: <4402885A.4010706@gmail.com> In-Reply-To: <4402885A.4010706@gmail.com> Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Feb 2006 05:38:58.0245 (UTC) FILETIME=[1AFEE750:01C63B60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 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 From simple-bounces@ietf.org Mon Feb 27 09:57:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjoR-0004OS-Fg; Mon, 27 Feb 2006 09:57:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjoQ-0004KB-B3 for simple@ietf.org; Mon, 27 Feb 2006 09:57:22 -0500 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDjoO-0005Cq-5U for simple@ietf.org; Mon, 27 Feb 2006 09:57:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Feb 2006 15:57:16 +0100 Message-ID: <31721CD4D0090B4BA32CBA5E2C40AE9001D5D7D5@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Filtering - 'include' element Thread-Index: AcY7rhlCK3nqqJ3BRdqZxIwI9AJtqg== From: To: X-OriginalArrivalTime: 27 Feb 2006 14:57:18.0718 (UTC) FILETIME=[1AD569E0:01C63BAE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 748ed3980abc7d4bd6a14905626ff64e Subject: [Simple] Filtering - 'include' 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: , Content-Type: multipart/mixed; boundary="===============0487031913==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0487031913== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63BAE.19EF6653" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63BAE.19EF6653 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hello, =20 I have again some questions on event notification filtering and I will = be very glad if someone could answer/comment them. =20 1. if some element is "included" (using an = filter-set/filter/what/include element), does it mean that all its = child-nodes are included as well? Example: =20 Suppose the "original" presence document to be: =20 open =20 I subscribe with the following filter: =20 /presence/tuple[id=3D'1'] =20 Will the resulting document look like this?: =20 open =20 What if I 'include' the namespace instead of xpath? Is the result same = as above? =20 =20 Thanks very much, in advance. =20 =20 Best regards, =20 Michal Burda Software Specialist TietoEnator a.s. Czech Software Centre Direct: +420 599 096 020 Fax: +420 599 096 110 E-mail: michal.burda@tietoenator.com V=FDstavn=ED 292/13 CZ-709 16 Ostrava CZECH REPUBLIC =20 www.tieotoenator.com =20 =20 Please note: The information contained in this message may be legally = privileged and confidential and protected from disclosure. If the reader = of this message is not the intended recipient, you are hereby notified = that any unauthorised use, distribution or copying of this communication = is strictly prohibited. If you have received this communication in = error, please notify us immediately by replying to the message and = deleting it from your computer. Thank you. =20 ------_=_NextPart_001_01C63BAE.19EF6653 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have again some questions on event notification = filtering and I will be very glad if someone could answer/comment = them.

 

1. if some element is „included“ (using = an filter-set/filter/what/include element), does it mean that all its child-nodes are included as well? = Example:

 

Suppose the „original“ presence document = to be:

 

<presence ...>

=A0 <tuple = id=3D“1“>

=A0=A0=A0 <status><basic>open</basic></status>

=A0 </tuple>

</presence>

 

I subscribe with the following = filter:

 

<filter-set>

=A0 <filter = id=3D“f1“>

=A0=A0=A0 <what>

=A0=A0 =A0=A0=A0<include = type=3D“xpath“>/presence/tuple[id=3D‘1‘]</i= nclude>

=A0=A0=A0 </what>

=A0 </filter>

</filter-set>

 

Will the resulting document look like = this?:

 

<presence ...>

=A0 <tuple = id=3D“1“>

=A0=A0=A0 <status><basic>open</basic></status>

=A0 </tuple>

</presence>

 

What if I ‚include‘ the namespace instead = of xpath? Is the result same as above?

 

 

Thanks very much, in = advance.

 

 

Best regards,

 

Michal = Burda

Software = Specialist

= TietoEnator a.s.

Czech Software = Centre

Direct: +420 599 = 096 020

Fax: +420 599 = 096 110

E-mail: michal.burda@tietoenator.com=
V=FDstavn=ED = 292/13

CZ-709 16 = Ostrava

CZECH = REPUBLIC

 =

www.tieotoenator.com=

 =

Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this = message is not the intended recipient, you are hereby notified that any = unauthorised use, distribution or copying of this communication is strictly prohibited. If = you have received this communication in error, please notify us immediately = by replying to the message and deleting it from your computer. Thank = you.

 

------_=_NextPart_001_01C63BAE.19EF6653-- --===============0487031913== 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 --===============0487031913==-- From simple-bounces@ietf.org Mon Feb 27 10:15:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDk5Y-0005LG-AN; Mon, 27 Feb 2006 10:15:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDk5X-0005L8-4b for simple@ietf.org; Mon, 27 Feb 2006 10:15:03 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDk5V-0005wi-HG for simple@ietf.org; Mon, 27 Feb 2006 10:15:03 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 3DD9619447F for ; Mon, 27 Feb 2006 16:15:00 +0100 (CET) Received: from [192.168.1.106] ([192.168.1.106]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Feb 2006 16:13:31 +0100 In-Reply-To: <31721CD4D0090B4BA32CBA5E2C40AE9001D5D7D5@carrera.eu.tieto.com> References: <31721CD4D0090B4BA32CBA5E2C40AE9001D5D7D5@carrera.eu.tieto.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <42904347673ec1c9a9f5da01798b9ba9@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Simple] Filtering - 'include' element Date: Mon, 27 Feb 2006 16:15:22 +0100 To: X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 27 Feb 2006 15:13:31.0160 (UTC) FILETIME=[5E744980:01C63BB0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 include whatever is mandatory according to the schema in order=20= for the xml document to be valid. Hisham On Feb 27, 2006, at 3:57 PM, wrote: > > Hello, > =A0 > I have again some questions on event notification filtering and I will=20= > be very glad if someone could answer/comment them. > =A0 > 1. if some element is =84included=93 (using an=20 > filter-set/filter/what/include element), does it mean that all its=20 > child-nodes are included as well? Example: > =A0 > Suppose the =84original=93 presence document to be: > =A0 > > =A0 > =A0=A0=A0 open > =A0 > > =A0 > I subscribe with the following filter: > =A0 > > =A0 > =A0=A0=A0 > =A0=A0 =A0=A0=A0/presence/tuple[id=3D=911=91] > =A0=A0=A0 > =A0 > > =A0 > Will the resulting document look like this?: > =A0 > > =A0 > =A0=A0=A0 open > =A0 > > =A0 > What if I =82include=91 the namespace instead of xpath? Is the result = same=20 > as above? > =A0 > =A0 > Thanks very much, in advance. > =A0 > =A0 > Best regards, > =A0 > Michal Burda > Software Specialist > > TietoEnator a.s. > Czech Software Centre > Direct: +420 599 096 020 > Fax: +420 599 096 110 > E-mail: michal.burda@tietoenator.com > V=FDstavn=ED 292/13 > CZ-709=A016 Ostrava > CZECH REPUBLIC > =A0 > www.tieotoenator.com > =A0 > Please note: The information contained in this message may be legally=20= > privileged and confidential and protected from disclosure. If the=20 > reader of this message is not the intended recipient, you are hereby=20= > notified that any unauthorised use, distribution or copying of this=20 > communication is strictly prohibited. If you have received this=20 > communication in error, please notify us immediately by replying to=20 > the message and deleting it from your computer. Thank you. > =A0 > _______________________________________________ > 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 Feb 27 13:01:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDmg8-0002Me-Ds; Mon, 27 Feb 2006 13:01:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDmg6-0002Lu-NH for simple@ietf.org; Mon, 27 Feb 2006 13:00:58 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDmg5-00042B-8U for simple@ietf.org; Mon, 27 Feb 2006 13:00: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 C4653194480 for ; Mon, 27 Feb 2006 19:00:55 +0100 (CET) Received: from [192.168.1.106] ([192.168.1.106]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Feb 2006 18:59:26 +0100 Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: <146291bde0393faae580352e0a276949@telio.no> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: simple@ietf.org WG From: Hisham Khartabil Date: Mon, 27 Feb 2006 19:01:17 +0100 X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 27 Feb 2006 17:59:26.0545 (UTC) FILETIME=[8C537C10:01C63BC7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Simple] IM Receipts X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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 Eric Burger and I tried to merge our IM delivery notification drafts but failed, mainly because we had differences in opinions on what the requirements are and about the complexity of the solution. So we submitted individual I-Ds again hoping that the community can help pick and chose from the 2 drafts. I have renamed the draft since IM "delivery report" terminology was taken by MSRP. I now call it IM receipts. http://www.ietf.org/internet-drafts/draft-khartabil-simple-im-receipts -00.txt Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 27 15:42:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDpCk-0002Jg-RW; Mon, 27 Feb 2006 15:42:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDpCj-0002Is-B1 for simple@ietf.org; Mon, 27 Feb 2006 15:42:49 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDnff-0006E4-6e for simple@ietf.org; Mon, 27 Feb 2006 14:04:35 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FDnNJ-00020M-VG for simple@ietf.org; Mon, 27 Feb 2006 13:45:40 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1RIjliL010247 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 27 Feb 2006 12:45:49 -0600 In-Reply-To: <44029071.3080507@cisco.com> References: <4402885A.4010706@gmail.com> <44029071.3080507@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <01DA2537-D6A9-45E3-878D-1FFA716944C0@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Simple]Question on MESSAGE Date: Mon, 27 Feb 2006 12:45:32 -0600 To: Michael Zhou , Ren-Huang Liou X-Mailer: Apple Mail (2.746.2) X-Spam-Score: -2.3 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 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. > Note that sending sequences of MESSAGE inside an INVITE dialog is NOT the preferred way to do session-mode IM. The preferred way to do session-mode IM is to use the INVITE transaction to establish an MSRP session. MSRP sessions are mostly documented in draft-ietf-simple- message-sessions-13.txt, which is nearing completion. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 27 18:50:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDs8L-0002mZ-1j; Mon, 27 Feb 2006 18:50:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDs7x-00022l-4J; Mon, 27 Feb 2006 18:50:05 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDs7u-0007JU-Rs; Mon, 27 Feb 2006 18:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k1RNo2BX013763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FDs7u-0005jl-Gv; Mon, 27 Feb 2006 18: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: Mon, 27 Feb 2006 18:50:02 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-14.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 Message Session Relay Protocol Author(s) : B. Campbell, et al. Filename : draft-ietf-simple-message-sessions-14.txt Pages : 59 Date : 2006-2-27 This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-14.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-message-sessions-14.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-message-sessions-14.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-2-27160339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-27160339.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 Tue Feb 28 10:08:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE6SM-0003mT-2D; Tue, 28 Feb 2006 10:08:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE6SK-0003kA-1Z for simple@ietf.org; Tue, 28 Feb 2006 10:08:04 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE6SI-0006aJ-G3 for simple@ietf.org; Tue, 28 Feb 2006 10:08:04 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id k1SF81Qk142474 for ; Tue, 28 Feb 2006 15:08:01 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k1SF8GwQ203064 for ; Tue, 28 Feb 2006 16:08:16 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k1SF81ns001874 for ; Tue, 28 Feb 2006 16:08:01 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k1SF81Ta001866 for ; Tue, 28 Feb 2006 16:08:01 +0100 In-Reply-To: <01DA2537-D6A9-45E3-878D-1FFA716944C0@softarmor.com> Cc: Simple WG Subject: Re: [Simple]Question on MESSAGE MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Avshalom Houri Message-ID: Date: Tue, 28 Feb 2006 17:08:15 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 | November 16, 2005) at 28/02/2006 17:08:16, Serialize complete at 28/02/2006 17:08:16 X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-BeenThere: simple@ietf.org X-Mailman-Version: 2.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="===============1255022058==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============1255022058== Content-Type: multipart/alternative; boundary="=_alternative 0052FD97C2257123_=" This is a multipart message in MIME format. --=_alternative 0052FD97C2257123_= Content-Type: text/plain; charset="US-ASCII" Note also that by design there is no contact header in MESSAGE. This was done to prevent creating a session via MESSAGE. --Avshalom Dean Willis 27-02-06 08:45 PM To Michael Zhou , Ren-Huang Liou cc Simple WG Subject Re: [Simple]Question on MESSAGE 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. > Note that sending sequences of MESSAGE inside an INVITE dialog is NOT the preferred way to do session-mode IM. The preferred way to do session-mode IM is to use the INVITE transaction to establish an MSRP session. MSRP sessions are mostly documented in draft-ietf-simple- message-sessions-13.txt, which is nearing completion. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --=_alternative 0052FD97C2257123_= Content-Type: text/html; charset="US-ASCII"
Note also that by design there is no contact header in MESSAGE.
This was done to prevent creating a session via MESSAGE.

--Avshalom



Dean Willis <dean.willis@softarmor.com>

27-02-06 08:45 PM

To
Michael Zhou <xmzhou@cisco.com>, Ren-Huang Liou <icq.cis92@gmail.com>
cc
Simple WG <simple@ietf.org>
Subject
Re: [Simple]Question on MESSAGE






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.
>


Note that sending sequences of MESSAGE inside an INVITE dialog is NOT  
the preferred way to do session-mode IM. The preferred way to do  
session-mode IM is to use the INVITE transaction to establish an MSRP  
session. MSRP sessions are mostly documented in draft-ietf-simple-
message-sessions-13.txt, which is nearing completion.

--
Dean


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
--=_alternative 0052FD97C2257123_=-- --===============1255022058== 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 --===============1255022058==-- From simple-bounces@ietf.org Tue Feb 28 10:34:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE6sD-0000bn-58; Tue, 28 Feb 2006 10:34:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE6sB-0000ZH-I5 for simple@ietf.org; Tue, 28 Feb 2006 10:34:47 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE6s9-0007Vv-MM for simple@ietf.org; Tue, 28 Feb 2006 10:34:47 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C6C1E4F0001; Tue, 28 Feb 2006 16:34:44 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 16:34:43 +0100 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 16:34:43 +0100 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 09:34:39 -0600 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, 28 Feb 2006 10:34:37 -0500 Message-ID: <95D8C1105D54EB41864F8831E6C4EB75A4C7BF@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] IMDN? Thread-Index: AcY1Ku9bQiSkaq/BQrarHN5iuel5lQHUEItQ From: "Nadia Bishai \(QC/EMC\)" To: "Burger, Eric" , "Simple WG" X-OriginalArrivalTime: 28 Feb 2006 15:34:39.0456 (UTC) FILETIME=[7CD4A600:01C63C7C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 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