From prasun.bheri@gmail.com Mon Feb 6 23:40:30 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F404C21F879E for ; Mon, 6 Feb 2012 23:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdbBQIlM4M8a for ; Mon, 6 Feb 2012 23:40:29 -0800 (PST) Received: from mail-lpp01m020-f172.google.com (mail-lpp01m020-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 73BFB21F8797 for ; Mon, 6 Feb 2012 23:40:27 -0800 (PST) Received: by lbbgk8 with SMTP id gk8so1639385lbb.31 for ; Mon, 06 Feb 2012 23:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=Th1b65gi8LKG1Nk0QWnx4IFGhQq1w7AMKXuz1Mn1Hak=; b=If4MUAkAgVVypGzDJn7rHxZfd6K/vBgrWtraCHdvnK5Y1m2yFABBAfK19UihLom5/i cjENSrXuSHlBMUF09Xd9+KmpAc6xF/Aqq6NywziLfuibuj0aNTLJCNolqma26ind1Nwy L8mrf5MR5hl2SjsEf53eoP1X/XMBb6PdVTFus= Received: by 10.112.83.42 with SMTP id n10mr5938715lby.101.1328600426299; Mon, 06 Feb 2012 23:40:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.3.234 with HTTP; Mon, 6 Feb 2012 23:39:46 -0800 (PST) From: prasun bheri Date: Tue, 7 Feb 2012 13:09:46 +0530 Message-ID: To: Simple@ietf.org Content-Type: multipart/alternative; boundary=f46d0401fc4175422404b85ae4ca Subject: [Simple] Queries in regards to msrp 200 ok X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 07:40:30 -0000 --f46d0401fc4175422404b85ae4ca Content-Type: text/plain; charset=ISO-8859-1 Hi, Is it required to include Message-id header in '200 ok'?. RFC 4975 examples doesn't contain this header in '200 ok', however RFC 4976 clearly included Message-ID in '200 ok' message. Is it required to send '200 ok' in response to an msrp report? Thanks & Regards Prasun --f46d0401fc4175422404b85ae4ca Content-Type: text/html; charset=ISO-8859-1 Hi,

Is it required to include Message-id header in '200 ok'?. RFC 4975 examples doesn't contain this header in '200 ok', however RFC 4976 clearly included Message-ID in '200 ok' message.

Is it required to send '200 ok' in response to an msrp report?

Thanks & Regards
Prasun
--f46d0401fc4175422404b85ae4ca-- From fluffy@fluffy.im Tue Feb 7 09:43:32 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621BB21F88C1; Tue, 7 Feb 2012 09:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbIKSxrf4AIB; Tue, 7 Feb 2012 09:43:31 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 73F8321F870E; Tue, 7 Feb 2012 09:43:31 -0800 (PST) Received: by iagf6 with SMTP id f6so12466905iag.31 for ; Tue, 07 Feb 2012 09:43:31 -0800 (PST) Received: by 10.42.136.69 with SMTP id s5mr22422583ict.20.1328636611034; Tue, 07 Feb 2012 09:43:31 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id ch2sm26025283igb.4.2012.02.07.09.43.28 (version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 09:43:29 -0800 (PST) Sender: Cullen Jennings From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Feb 2012 10:43:27 -0700 Message-Id: <510CB696-780B-44D0-A72C-EA5BD9E479BD@iii.ca> To: The IESG , draft-ietf-simple-chat.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: tsv-area@ietf.org, Simple WG , Transport Directorate Subject: [Simple] tsv-dir review of draft-ietf-simple-chat-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 17:43:32 -0000 I've reviewed this document as part of the transport area directorate's = ongoing effort to review key IETF documents. These comments were written = primarily for the transport area directors, but are copied to the = document's authors for their information and to allow them to address = any issues raised. When done at the time of IETF Last Call, the authors = should consider this review together with any other last-call comments = they receive. Please always CC tsv-dir@ietf.org if you reply to or = forward this review. Summary: =46rom a transport point of view, this draft is ready for publication as = a PS RFC.=20 =46rom a transport and congestion point of view, this draft does not = change any of the underling MSRP behavior and thus this draft is the = same as MSRP (RFC 4975 & RFC 4976).=20 Details: There is one issue in the draft related to transport that, if addressed, = I think would improve the draft.=20 Consider the case of a chat room that is receiving messages at a rate = of 10 per second (perhaps bad-attitude during the IESG plenary) and also = has some clients in the chat room that can only receiving messages at a = maximum rate of 5 per second ( perhaps an iphone via VPN over 2G). = Section 6.1 does not say what should happen in this case.=20 From miguel.a.garcia@ericsson.com Wed Feb 8 00:10:55 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD98121F86D1 for ; Wed, 8 Feb 2012 00:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.111 X-Spam-Level: X-Spam-Status: No, score=-10.111 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxTM1XgarB2D for ; Wed, 8 Feb 2012 00:10:53 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 79C7421F865D for ; Wed, 8 Feb 2012 00:10:51 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-f3-4f322e0b87ff Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EB.13.02613.B0E223F4; Wed, 8 Feb 2012 09:10:51 +0100 (CET) Received: from [159.107.24.212] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Wed, 8 Feb 2012 09:10:50 +0100 Message-ID: <4F322E09.2020801@ericsson.com> Date: Wed, 8 Feb 2012 09:10:49 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Aki Niemi Subject: [Simple] SIMPLE chat: Status codes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 08:10:55 -0000 The SIMPLE chat draft, draft-ietf-simple-chat-13t.txt, went through the Apps review. The reviewer had a comment that requires a bit of discussion in the working group before we take an action. Here is the issue. --- In Section 7.1: The reservation of a nickname can fail, e.g. if the NICKNAME request contains a malformed or non-existent Use-Nickname header field, or if the same nickname has already been reserved by another participant (i.e., by another URI) in the chat room. The validation can also fail where the sender of the message is not entitled to reserve the nickname. In any of these cases the MSRP switch MUST answer the NICKNAME request with a 423 response. The semantics of the 423 response are: "Nickname usage failed; the nickname is not allocated to this user". It would be better to use different response codes for different error conditions. --- So, here is the discussion I would like to have. Do we need different response code for each of these issues? We can do: a) Do nothing and motivate why a single response code is sufficient b) Create a response code for each error situation. This could be, e.g.: 424 Malformed nickname 425 Nickname already in use 507 Not allowed to reserve a nickname Notice that the "Not allowed to reserve nickname" should have a 500-class response to indicate a permanent failure, as opposed to the other two error codes, where a new request fixing the problem may succed. Note: i just noticed that the 423 status code is already allocated (see http://www.iana.org/assignments/msrp-parameters/msrp-parameters.xml ) so I have chosen the next available status code. And while composing this e-mail, I revised the rest of the status codes that we are requesting, and we have requested a status code 428 for indicating "Private messages not supported". I think this should be a 500-class status code as well, since it is a permanent failure. Can we also move this one to 508? Please comment. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Wed Feb 8 02:38:39 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3CE21F85D2; Wed, 8 Feb 2012 02:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.162 X-Spam-Level: X-Spam-Status: No, score=-10.162 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttyl2WW1ML2O; Wed, 8 Feb 2012 02:38:39 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6247121F85D8; Wed, 8 Feb 2012 02:38:38 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-03-4f3250acc309 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B3.B6.27041.CA0523F4; Wed, 8 Feb 2012 11:38:37 +0100 (CET) Received: from [159.107.24.212] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 8 Feb 2012 11:38:36 +0100 Message-ID: <4F3250AB.4060307@ericsson.com> Date: Wed, 8 Feb 2012 11:38:35 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Cullen Jennings References: <510CB696-780B-44D0-A72C-EA5BD9E479BD@iii.ca> In-Reply-To: <510CB696-780B-44D0-A72C-EA5BD9E479BD@iii.ca> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-chat.all@tools.ietf.org" , Simple WG , "tsv-area@ietf.org" , The IESG , Transport Directorate Subject: Re: [Simple] tsv-dir review of draft-ietf-simple-chat-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 10:38:39 -0000 Hi Cullen, Thanks for your review. See inline comments. On 07/02/2012 18:43, Cullen Jennings wrote: > Consider the case of a chat room that is receiving messages at a rate > of 10 per second (perhaps bad-attitude during the IESG plenary) and > also has some clients in the chat room that can only receiving > messages at a maximum rate of 5 per second ( perhaps an iphone via VPN > over 2G). Section 6.1 does not say what should happen in this case. I understand the problem description. The question is whether we want to make the application layer aware of potential congestion and take actions on it. I don't know how the chat room application could in the first place detect congestion. Any ideas of what to write in the draft are highly appreciated. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From saul@ag-projects.com Thu Feb 9 00:55:05 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0600B21F8631 for ; Thu, 9 Feb 2012 00:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RymMkRsj8Sxw for ; Thu, 9 Feb 2012 00:55:04 -0800 (PST) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9310321F8633 for ; Thu, 9 Feb 2012 00:55:03 -0800 (PST) Received: by mail.sipthor.net (Postfix, from userid 5001) id EA208B01A5; Thu, 9 Feb 2012 09:55:01 +0100 (CET) Received: from [192.168.99.45] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 7EB13B019A; Thu, 9 Feb 2012 09:55:00 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Saul Ibarra Corretge In-Reply-To: <4F322E09.2020801@ericsson.com> Date: Thu, 9 Feb 2012 09:54:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1295910B-9B83-4829-B308-CC921B73D147@ag-projects.com> References: <4F322E09.2020801@ericsson.com> To: Miguel A. Garcia X-Mailer: Apple Mail (2.1084) Cc: Simple WG , Aki Niemi Subject: Re: [Simple] SIMPLE chat: Status codes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 08:55:05 -0000 Hi, On Feb 8, 2012, at 9:10 AM, Miguel A. Garcia wrote: > The SIMPLE chat draft, draft-ietf-simple-chat-13t.txt, went through = the Apps review. The reviewer had a comment that requires a bit of = discussion in the working group before we take an action. Here is the = issue. >=20 > --- > In Section 7.1: >=20 > The reservation of a nickname can fail, e.g. if the NICKNAME = request > contains a malformed or non-existent Use-Nickname header field, or > if the same nickname has already been reserved by another > participant (i.e., by another URI) in the chat room. The > validation can also fail where the sender of the message is not > entitled to reserve the nickname. In any of these cases the MSRP > switch MUST answer the NICKNAME request with a 423 response. The > semantics of the 423 response are: "Nickname usage failed; the > nickname is not allocated to this user". >=20 > It would be better to use different response codes for different error > conditions. > --- >=20 > So, here is the discussion I would like to have. Do we need different = response code for each of these issues? We can do: >=20 I agree, some more fine grained error reporting would help applications = give better feedback. > a) Do nothing and motivate why a single response code is sufficient >=20 > b) Create a response code for each error situation. This could be, = e.g.: >=20 > 424 Malformed nickname > 425 Nickname already in use > 507 Not allowed to reserve a nickname >=20 > Notice that the "Not allowed to reserve nickname" should have a = 500-class response to indicate a permanent failure, as opposed to the = other two error codes, where a new request fixing the problem may = succed. These look just fine, user may just change the nickname and try again = (in the 4xx cases), which I think it'll be helpful. What about nickname policy? Lets say a focus doesn't allow "admin", = "root" and "god" as nicknames, should we consider that a malformed = nickname? It's not really malformed, it's explicitly forbidden. What = about this? 426 Forbidden nickname >=20 > Note: i just noticed that the 423 status code is already allocated = (see http://www.iana.org/assignments/msrp-parameters/msrp-parameters.xml = ) so I have chosen the next available status code. >=20 >=20 > And while composing this e-mail, I revised the rest of the status = codes that we are requesting, and we have requested a status code 428 = for indicating "Private messages not supported". I think this should be = a 500-class status code as well, since it is a permanent failure. Can we = also move this one to 508? >=20 Agreed. Regards, --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From miguel.a.garcia@ericsson.com Thu Feb 9 01:26:33 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF55E21F86C3 for ; Thu, 9 Feb 2012 01:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.208 X-Spam-Level: X-Spam-Status: No, score=-10.208 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycA6ubb1-2Yy for ; Thu, 9 Feb 2012 01:26:33 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C821121F86C1 for ; Thu, 9 Feb 2012 01:26:32 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-f8-4f33914736c1 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 47.18.02613.741933F4; Thu, 9 Feb 2012 10:26:31 +0100 (CET) Received: from [159.107.24.225] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 9 Feb 2012 10:26:31 +0100 Message-ID: <4F339146.4030609@ericsson.com> Date: Thu, 9 Feb 2012 10:26:30 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Saul Ibarra Corretge References: <4F322E09.2020801@ericsson.com> <1295910B-9B83-4829-B308-CC921B73D147@ag-projects.com> In-Reply-To: <1295910B-9B83-4829-B308-CC921B73D147@ag-projects.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Simple WG , Aki Niemi Subject: Re: [Simple] SIMPLE chat: Status codes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 09:26:34 -0000 Hi Saul, see inline. On 09/02/2012 9:54, Saul Ibarra Corretge wrote: > Hi, > > On Feb 8, 2012, at 9:10 AM, Miguel A. Garcia wrote: > >> The SIMPLE chat draft, draft-ietf-simple-chat-13t.txt, went through the Apps review. The reviewer had a comment that requires a bit of discussion in the working group before we take an action. Here is the issue. >> >> --- >> In Section 7.1: >> >> The reservation of a nickname can fail, e.g. if the NICKNAME request >> contains a malformed or non-existent Use-Nickname header field, or >> if the same nickname has already been reserved by another >> participant (i.e., by another URI) in the chat room. The >> validation can also fail where the sender of the message is not >> entitled to reserve the nickname. In any of these cases the MSRP >> switch MUST answer the NICKNAME request with a 423 response. The >> semantics of the 423 response are: "Nickname usage failed; the >> nickname is not allocated to this user". >> >> It would be better to use different response codes for different error >> conditions. >> --- >> >> So, here is the discussion I would like to have. Do we need different response code for each of these issues? We can do: >> > > I agree, some more fine grained error reporting would help applications give better feedback. > >> a) Do nothing and motivate why a single response code is sufficient >> >> b) Create a response code for each error situation. This could be, e.g.: >> >> 424 Malformed nickname >> 425 Nickname already in use >> 507 Not allowed to reserve a nickname >> >> Notice that the "Not allowed to reserve nickname" should have a 500-class response to indicate a permanent failure, as opposed to the other two error codes, where a new request fixing the problem may succed. > > These look just fine, user may just change the nickname and try again (in the 4xx cases), which I think it'll be helpful. > > What about nickname policy? Lets say a focus doesn't allow "admin", "root" and "god" as nicknames, should we consider that a malformed nickname? It's not really malformed, it's explicitly forbidden. What about this? > 426 Forbidden nickname I think these special nicknames are permanently reserved, so, they are in use (by the system). I don't care much of the textual representation of the status code, since this is for us human to understand. The important think is that the semantics are clear. /Miguel > >> >> Note: i just noticed that the 423 status code is already allocated (see http://www.iana.org/assignments/msrp-parameters/msrp-parameters.xml ) so I have chosen the next available status code. >> >> >> And while composing this e-mail, I revised the rest of the status codes that we are requesting, and we have requested a status code 428 for indicating "Private messages not supported". I think this should be a 500-class status code as well, since it is a permanent failure. Can we also move this one to 508? >> > > Agreed. > > > Regards, > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From saul@ag-projects.com Thu Feb 9 02:00:27 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC4721F86D0 for ; Thu, 9 Feb 2012 02:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5VCRZeVnCpa for ; Thu, 9 Feb 2012 02:00:27 -0800 (PST) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id EA48121F86CE for ; Thu, 9 Feb 2012 02:00:26 -0800 (PST) Received: by mail.sipthor.net (Postfix, from userid 5001) id E215EB01A4; Thu, 9 Feb 2012 11:00:25 +0100 (CET) Received: from [192.168.99.45] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 6784BB019B; Thu, 9 Feb 2012 11:00:25 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Saul Ibarra Corretge In-Reply-To: <4F339146.4030609@ericsson.com> Date: Thu, 9 Feb 2012 11:00:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <709DBF9A-FCB7-4852-86D7-3BD1DADF6EA1@ag-projects.com> References: <4F322E09.2020801@ericsson.com> <1295910B-9B83-4829-B308-CC921B73D147@ag-projects.com> <4F339146.4030609@ericsson.com> To: Miguel A. Garcia X-Mailer: Apple Mail (2.1084) Cc: Simple WG , Aki Niemi Subject: Re: [Simple] SIMPLE chat: Status codes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 10:00:27 -0000 Hi, >=20 > I think these special nicknames are permanently reserved, so, they are = in use (by the system). >=20 > I don't care much of the textual representation of the status code, = since this is for us human to understand. The important think is that = the semantics are clear. >=20 Ok, bad example :-) I was thinking about some nicknames that could = perhaps be disabled by the administrator, like bad words or some special = names. This case is semantically different than a malformed nickname = (it's not malformed) and it's also not "not in use" (nobody can use it, = actually) so IMHO a new code could be appropriate. Regards, --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From ben@estacado.net Thu Feb 9 14:30:24 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E40A21E8058 for ; Thu, 9 Feb 2012 14:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwrPls+hE8v9 for ; Thu, 9 Feb 2012 14:30:23 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id B019D21E804B for ; Thu, 9 Feb 2012 14:30:23 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q19MUEUF087375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Feb 2012 16:30:19 -0600 (CST) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <4F322E09.2020801@ericsson.com> Date: Thu, 9 Feb 2012 16:30:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F322E09.2020801@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1257) Cc: Simple WG , Aki Niemi Subject: Re: [Simple] SIMPLE chat: Status codes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 22:30:24 -0000 (as individual) On Feb 8, 2012, at 2:10 AM, Miguel A. Garcia wrote: > Notice that the "Not allowed to reserve nickname" should have a = 500-class response to indicate a permanent failure, as opposed to the = other two error codes, where a new request fixing the problem may = succed. Keep in mind the MSRP error codes don't formally map to local and global = failures. But I'm happy to stick to the informal convention of picking = numbers similar to those for SIP or HTTP :-)= From ben@estacado.net Thu Feb 9 14:34:00 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A85B21E8050 for ; Thu, 9 Feb 2012 14:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1o-mHWdtajyZ for ; Thu, 9 Feb 2012 14:33:59 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F38D11E8073 for ; Thu, 9 Feb 2012 14:33:59 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q19MXmea087861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Feb 2012 16:33:53 -0600 (CST) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: <709DBF9A-FCB7-4852-86D7-3BD1DADF6EA1@ag-projects.com> Date: Thu, 9 Feb 2012 16:33:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <81C46F45-F71F-4F7F-9A5B-5FCCD9C4B7FF@estacado.net> References: <4F322E09.2020801@ericsson.com> <1295910B-9B83-4829-B308-CC921B73D147@ag-projects.com> <4F339146.4030609@ericsson.com> <709DBF9A-FCB7-4852-86D7-3BD1DADF6EA1@ag-projects.com> To: Saul Ibarra Corretge X-Mailer: Apple Mail (2.1257) Cc: Simple WG , Aki Niemi Subject: Re: [Simple] SIMPLE chat: Status codes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 22:34:00 -0000 (as individual) I have mixed emotions on the need for more granular nickname errors. I = see the point, but I'm also hesitant to start a response code explosion. In this case, I guess it depends on what we expect a client = implementation to do different with the different conditions. If the = answer is "display the error to the end-user along with the comment = text" for all cases, I don't find that very convincing. On Feb 9, 2012, at 4:00 AM, Saul Ibarra Corretge wrote: > Hi, >=20 >>=20 >> I think these special nicknames are permanently reserved, so, they = are in use (by the system). >>=20 >> I don't care much of the textual representation of the status code, = since this is for us human to understand. The important think is that = the semantics are clear. >>=20 >=20 > Ok, bad example :-) I was thinking about some nicknames that could = perhaps be disabled by the administrator, like bad words or some special = names. This case is semantically different than a malformed nickname = (it's not malformed) and it's also not "not in use" (nobody can use it, = actually) so IMHO a new code could be appropriate. >=20 >=20 > Regards, >=20 > --=20 > Sa=FAl Ibarra Corretg=E9 > AG Projects >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@estacado.net Thu Feb 9 14:43:17 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2FB21E804B for ; Thu, 9 Feb 2012 14:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIwK3kgyhhTj for ; Thu, 9 Feb 2012 14:43:16 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 888E721E8044 for ; Thu, 9 Feb 2012 14:43:15 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q19Mh88M089538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Feb 2012 16:43:13 -0600 (CST) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: Date: Thu, 9 Feb 2012 16:43:08 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <750E3836-9A4B-429B-85BE-900DD6E568E5@estacado.net> References: To: prasun bheri X-Mailer: Apple Mail (2.1257) Cc: Simple@ietf.org Subject: Re: [Simple] Queries in regards to msrp 200 ok X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 22:43:17 -0000 On Feb 7, 2012, at 1:39 AM, prasun bheri wrote: > Hi, >=20 > Is it required to include Message-id header in '200 ok'?. RFC 4975 = examples doesn't contain this header in '200 ok', however RFC 4976 = clearly included Message-ID in '200 ok' message. >=20 That depends on whether it is sent in a "response" vs a "report". A = "response" is in response to a particular request. (e.g. a SEND = request.). You don't need the Message-ID, but it's not forbidden. OTOH, = if it is sent in a report, Message-ID is required, since a success = report may refer to all or part of the full message content. > Is it required to send '200 ok' in response to an msrp report? No. In fact, it's forbidden in the 2nd to last paragraph of section = 7.1.1. >=20 > Thanks & Regards > Prasun > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@estacado.net Mon Feb 13 06:46:58 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C941A21F8574 for ; Mon, 13 Feb 2012 06:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpCB1xqHacn5 for ; Mon, 13 Feb 2012 06:46:57 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB5821F8573 for ; Mon, 13 Feb 2012 06:46:57 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q1DEkfOa031372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Feb 2012 08:46:46 -0600 (CST) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: <81C46F45-F71F-4F7F-9A5B-5FCCD9C4B7FF@estacado.net> Date: Mon, 13 Feb 2012 08:46:54 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <808CE579-DB82-42D0-B023-B34AF17F650A@estacado.net> References: <4F322E09.2020801@ericsson.com> <1295910B-9B83-4829-B308-CC921B73D147@ag-projects.com> <4F339146.4030609@ericsson.com> <709DBF9A-FCB7-4852-86D7-3BD1DADF6EA1@ag-projects.com> <81C46F45-F71F-4F7F-9A5B-5FCCD9C4B7FF@estacado.net> To: Simple WG X-Mailer: Apple Mail (2.1257) Cc: Aki Niemi Subject: Re: [Simple] SIMPLE chat: Status codes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 14:46:59 -0000 (as chair) Does anyone else have thoughts on this question? The draft just finished = IETF last call. We'd like to get an "approval candidate" back to the = IESG as soon as possible. Thanks! Ben. On Feb 9, 2012, at 4:33 PM, Ben Campbell wrote: > (as individual) >=20 > I have mixed emotions on the need for more granular nickname errors. I = see the point, but I'm also hesitant to start a response code explosion. >=20 > In this case, I guess it depends on what we expect a client = implementation to do different with the different conditions. If the = answer is "display the error to the end-user along with the comment = text" for all cases, I don't find that very convincing. >=20 > On Feb 9, 2012, at 4:00 AM, Saul Ibarra Corretge wrote: >=20 >> Hi, >>=20 >>>=20 >>> I think these special nicknames are permanently reserved, so, they = are in use (by the system). >>>=20 >>> I don't care much of the textual representation of the status code, = since this is for us human to understand. The important think is that = the semantics are clear. >>>=20 >>=20 >> Ok, bad example :-) I was thinking about some nicknames that could = perhaps be disabled by the administrator, like bad words or some special = names. This case is semantically different than a malformed nickname = (it's not malformed) and it's also not "not in use" (nobody can use it, = actually) so IMHO a new code could be appropriate. >>=20 >>=20 >> Regards, >>=20 >> --=20 >> Sa=FAl Ibarra Corretg=E9 >> AG Projects >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From miguel.a.garcia@ericsson.com Mon Feb 13 06:59:15 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833F721F8570 for ; Mon, 13 Feb 2012 06:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.255 X-Spam-Level: X-Spam-Status: No, score=-10.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osxcijxHpmIi for ; Mon, 13 Feb 2012 06:59:14 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8937D21F858A for ; Mon, 13 Feb 2012 06:59:14 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-80-4f392541bd53 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B4.94.01970.145293F4; Mon, 13 Feb 2012 15:59:13 +0100 (CET) Received: from [159.107.24.213] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Mon, 13 Feb 2012 15:59:12 +0100 Message-ID: <4F39253F.7050204@ericsson.com> Date: Mon, 13 Feb 2012 15:59:11 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Ben Campbell References: <4F322E09.2020801@ericsson.com> <1295910B-9B83-4829-B308-CC921B73D147@ag-projects.com> <4F339146.4030609@ericsson.com> <709DBF9A-FCB7-4852-86D7-3BD1DADF6EA1@ag-projects.com> <81C46F45-F71F-4F7F-9A5B-5FCCD9C4B7FF@estacado.net> <808CE579-DB82-42D0-B023-B34AF17F650A@estacado.net> In-Reply-To: <808CE579-DB82-42D0-B023-B34AF17F650A@estacado.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Simple WG , Aki Niemi Subject: Re: [Simple] SIMPLE chat: Status codes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 14:59:15 -0000 I will try to give my perception, and propose something: - I believe there is a sentiment of providing as detailed as possible error codes. - However, we don't want an explosion of MSRP error codes for chat. My interpretation: perhaps we can take something in between. Where it is expected that the endpoint will do different things based on the received error code, we should differentiate them. Where it is not possible to justify the difference, we should try to use a single one. Based on that, I still think we should go with my earlier proposal: 424 Malformed nickname 425 Nickname reserved or already in use 507 Not allowed to reserve a nickname Saul wanted one more error code to indicate "Nickname not allowed by the policy". But I argued that this can be modeled as a permanently reserved nickname and a 425 response (the nickname is syntactically correct, but you cannot reserve it). So, the endpoint will take the same action: display to the user that it is not possible to reserve that nickname, and give the user the possibility to select another one. Can we go for this? /Miguel On 13/02/2012 15:46, Ben Campbell wrote: > (as chair) > > Does anyone else have thoughts on this question? The draft just finished IETF last call. We'd like to get an "approval candidate" back to the IESG as soon as possible. > > Thanks! > > Ben. > > On Feb 9, 2012, at 4:33 PM, Ben Campbell wrote: > >> (as individual) >> >> I have mixed emotions on the need for more granular nickname errors. I see the point, but I'm also hesitant to start a response code explosion. >> >> In this case, I guess it depends on what we expect a client implementation to do different with the different conditions. If the answer is "display the error to the end-user along with the comment text" for all cases, I don't find that very convincing. >> >> On Feb 9, 2012, at 4:00 AM, Saul Ibarra Corretge wrote: >> >>> Hi, >>> >>>> >>>> I think these special nicknames are permanently reserved, so, they are in use (by the system). >>>> >>>> I don't care much of the textual representation of the status code, since this is for us human to understand. The important think is that the semantics are clear. >>>> >>> >>> Ok, bad example :-) I was thinking about some nicknames that could perhaps be disabled by the administrator, like bad words or some special names. This case is semantically different than a malformed nickname (it's not malformed) and it's also not "not in use" (nobody can use it, actually) so IMHO a new code could be appropriate. >>> >>> >>> Regards, >>> >>> -- >>> Saúl Ibarra Corretgé >>> AG Projects >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ben@estacado.net Mon Feb 13 07:03:37 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02ADE21F847E for ; Mon, 13 Feb 2012 07:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fhEqKP-ii9N for ; Mon, 13 Feb 2012 07:03:36 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC5921F8484 for ; Mon, 13 Feb 2012 07:03:36 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q1DF3SsL034296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Feb 2012 09:03:33 -0600 (CST) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: <4F39253F.7050204@ericsson.com> Date: Mon, 13 Feb 2012 09:03:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2526CD8D-CEFF-447E-B432-AEE09F6C514D@estacado.net> References: <4F322E09.2020801@ericsson.com> <1295910B-9B83-4829-B308-CC921B73D147@ag-projects.com> <4F339146.4030609@ericsson.com> <709DBF9A-FCB7-4852-86D7-3BD1DADF6EA1@ag-projects.com> <81C46F45-F71F-4F7F-9A5B-5FCCD9C4B7FF@estacado.net> <808CE579-DB82-42D0-B023-B34AF17F650A@estacado.net> <4F39253F.7050204@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1257) Cc: Simple WG , Aki Niemi Subject: Re: [Simple] SIMPLE chat: Status codes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 15:03:37 -0000 On Feb 13, 2012, at 8:59 AM, Miguel A. Garcia wrote: > I will try to give my perception, and propose something: >=20 > - I believe there is a sentiment of providing as detailed as possible = error codes. > - However, we don't want an explosion of MSRP error codes for chat. >=20 > My interpretation: perhaps we can take something in between. Where it = is expected that the endpoint will do different things based on the = received error code, we should differentiate them. Where it is not = possible to justify the difference, we should try to use a single one. >=20 > Based on that, I still think we should go with my earlier proposal: >=20 > 424 Malformed nickname > 425 Nickname reserved or already in use > 507 Not allowed to reserve a nickname I agree with the first two. How is the 507 different than 403? The = requestor knows the context. Otherwise we could argue for a separate = version of "forbidden" for every possible action. >=20 >=20 > Saul wanted one more error code to indicate "Nickname not allowed by = the policy". But I argued that this can be modeled as a permanently = reserved nickname and a 425 response (the nickname is syntactically = correct, but you cannot reserve it). So, the endpoint will take the same = action: display to the user that it is not possible to reserve that = nickname, and give the user the possibility to select another one. >=20 > Can we go for this? >=20 > /Miguel >=20 > On 13/02/2012 15:46, Ben Campbell wrote: >> (as chair) >>=20 >> Does anyone else have thoughts on this question? The draft just = finished IETF last call. We'd like to get an "approval candidate" back = to the IESG as soon as possible. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> On Feb 9, 2012, at 4:33 PM, Ben Campbell wrote: >>=20 >>> (as individual) >>>=20 >>> I have mixed emotions on the need for more granular nickname errors. = I see the point, but I'm also hesitant to start a response code = explosion. >>>=20 >>> In this case, I guess it depends on what we expect a client = implementation to do different with the different conditions. If the = answer is "display the error to the end-user along with the comment = text" for all cases, I don't find that very convincing. >>>=20 >>> On Feb 9, 2012, at 4:00 AM, Saul Ibarra Corretge wrote: >>>=20 >>>> Hi, >>>>=20 >>>>>=20 >>>>> I think these special nicknames are permanently reserved, so, they = are in use (by the system). >>>>>=20 >>>>> I don't care much of the textual representation of the status = code, since this is for us human to understand. The important think is = that the semantics are clear. >>>>>=20 >>>>=20 >>>> Ok, bad example :-) I was thinking about some nicknames that could = perhaps be disabled by the administrator, like bad words or some special = names. This case is semantically different than a malformed nickname = (it's not malformed) and it's also not "not in use" (nobody can use it, = actually) so IMHO a new code could be appropriate. >>>>=20 >>>>=20 >>>> Regards, >>>>=20 >>>> -- >>>> Sa=FAl Ibarra Corretg=E9 >>>> AG Projects >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From fluffy@iii.ca Mon Feb 13 12:30:47 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25C921E801B; Mon, 13 Feb 2012 12:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKflDNSMjcE0; Mon, 13 Feb 2012 12:30:47 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDB121E8018; Mon, 13 Feb 2012 12:30:47 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BAFB622E253; Mon, 13 Feb 2012 15:30:37 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4F3250AB.4060307@ericsson.com> Date: Mon, 13 Feb 2012 13:30:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <510CB696-780B-44D0-A72C-EA5BD9E479BD@iii.ca> <4F3250AB.4060307@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1084) Cc: "draft-ietf-simple-chat.all@tools.ietf.org" , Transport Directorate , "tsv-area@ietf.org" , Simple WG , The IESG Subject: Re: [Simple] tsv-dir review of draft-ietf-simple-chat-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:30:47 -0000 On Feb 8, 2012, at 3:38 AM, Miguel A. Garcia wrote: > Hi Cullen, >=20 > Thanks for your review. See inline comments. >=20 > On 07/02/2012 18:43, Cullen Jennings wrote: >=20 >> Consider the case of a chat room that is receiving messages at a = rate >> of 10 per second (perhaps bad-attitude during the IESG plenary) and >> also has some clients in the chat room that can only receiving >> messages at a maximum rate of 5 per second ( perhaps an iphone via = VPN >> over 2G). Section 6.1 does not say what should happen in this case. >=20 > I understand the problem description. The question is whether we want = to make the application layer aware of potential congestion and take = actions on it. >=20 > I don't know how the chat room application could in the first place = detect congestion. Any ideas of what to write in the draft are highly = appreciated. Note - I'd be OK with publishing the document with no change but I think = some text would improve the draft. I think the most important part is just point out that this is a problem = and applications need to have a strategy to deal with it. I would not = prescribe a strategy that apps had to implement but instead have some = non normative strategies that an application might use. One strategy is = that is any client falls more than 10 seconds behind, that client get = disconnected.=20 From miguel.a.garcia@ericsson.com Mon Feb 13 22:33:07 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB0221E806B for ; Mon, 13 Feb 2012 22:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.268 X-Spam-Level: X-Spam-Status: No, score=-10.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5Lp-DKJTTIe for ; Mon, 13 Feb 2012 22:33:07 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B238321E8060 for ; Mon, 13 Feb 2012 22:33:06 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-fc-4f3a00208689 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 4C.23.01970.0200A3F4; Tue, 14 Feb 2012 07:33:05 +0100 (CET) Received: from [159.107.24.207] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Tue, 14 Feb 2012 07:33:04 +0100 Message-ID: <4F3A001F.5060404@ericsson.com> Date: Tue, 14 Feb 2012 07:33:03 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Ben Campbell References: <4F322E09.2020801@ericsson.com> <1295910B-9B83-4829-B308-CC921B73D147@ag-projects.com> <4F339146.4030609@ericsson.com> <709DBF9A-FCB7-4852-86D7-3BD1DADF6EA1@ag-projects.com> <81C46F45-F71F-4F7F-9A5B-5FCCD9C4B7FF@estacado.net> <808CE579-DB82-42D0-B023-B34AF17F650A@estacado.net> <4F39253F.7050204@ericsson.com> <2526CD8D-CEFF-447E-B432-AEE09F6C514D@estacado.net> In-Reply-To: <2526CD8D-CEFF-447E-B432-AEE09F6C514D@estacado.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] SIMPLE chat: Status codes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 06:33:07 -0000 hmmm... I agree with you Ben, the existing 403 code has the same semantics. So, let's revise the proposal. List of new codes used by the draft: 404 Failure to resolve recipient's URI 424 Malformed nickname 425 Nickname reserved or already in use 428 Private messages not supported Usage of existing codes: 403 Not allowed /Miguel On 13/02/2012 16:03, Ben Campbell wrote: > > On Feb 13, 2012, at 8:59 AM, Miguel A. Garcia wrote: > >> I will try to give my perception, and propose something: >> >> - I believe there is a sentiment of providing as detailed as possible error codes. >> - However, we don't want an explosion of MSRP error codes for chat. >> >> My interpretation: perhaps we can take something in between. Where it is expected that the endpoint will do different things based on the received error code, we should differentiate them. Where it is not possible to justify the difference, we should try to use a single one. >> >> Based on that, I still think we should go with my earlier proposal: >> >> 424 Malformed nickname >> 425 Nickname reserved or already in use >> 507 Not allowed to reserve a nickname > > I agree with the first two. How is the 507 different than 403? The requestor knows the context. Otherwise we could argue for a separate version of "forbidden" for every possible action. > >> >> >> Saul wanted one more error code to indicate "Nickname not allowed by the policy". But I argued that this can be modeled as a permanently reserved nickname and a 425 response (the nickname is syntactically correct, but you cannot reserve it). So, the endpoint will take the same action: display to the user that it is not possible to reserve that nickname, and give the user the possibility to select another one. >> >> Can we go for this? >> >> /Miguel >> >> On 13/02/2012 15:46, Ben Campbell wrote: >>> (as chair) >>> >>> Does anyone else have thoughts on this question? The draft just finished IETF last call. We'd like to get an "approval candidate" back to the IESG as soon as possible. >>> >>> Thanks! >>> >>> Ben. >>> >>> On Feb 9, 2012, at 4:33 PM, Ben Campbell wrote: >>> >>>> (as individual) >>>> >>>> I have mixed emotions on the need for more granular nickname errors. I see the point, but I'm also hesitant to start a response code explosion. >>>> >>>> In this case, I guess it depends on what we expect a client implementation to do different with the different conditions. If the answer is "display the error to the end-user along with the comment text" for all cases, I don't find that very convincing. >>>> >>>> On Feb 9, 2012, at 4:00 AM, Saul Ibarra Corretge wrote: >>>> >>>>> Hi, >>>>> >>>>>> >>>>>> I think these special nicknames are permanently reserved, so, they are in use (by the system). >>>>>> >>>>>> I don't care much of the textual representation of the status code, since this is for us human to understand. The important think is that the semantics are clear. >>>>>> >>>>> >>>>> Ok, bad example :-) I was thinking about some nicknames that could perhaps be disabled by the administrator, like bad words or some special names. This case is semantically different than a malformed nickname (it's not malformed) and it's also not "not in use" (nobody can use it, actually) so IMHO a new code could be appropriate. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> -- >>>>> Saúl Ibarra Corretgé >>>>> AG Projects >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/simple >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>> >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Mon Feb 13 22:51:23 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B8921F86FD for ; Mon, 13 Feb 2012 22:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.292 X-Spam-Level: X-Spam-Status: No, score=-10.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IW6SbkD0tyzW for ; Mon, 13 Feb 2012 22:51:22 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 919C921F86F2 for ; Mon, 13 Feb 2012 22:51:21 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-2d-4f3a0468aab2 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DB.8E.27041.8640A3F4; Tue, 14 Feb 2012 07:51:20 +0100 (CET) Received: from [159.107.24.207] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Tue, 14 Feb 2012 07:51:19 +0100 Message-ID: <4F3A0467.5020705@ericsson.com> Date: Tue, 14 Feb 2012 07:51:19 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Cullen Jennings References: <510CB696-780B-44D0-A72C-EA5BD9E479BD@iii.ca> <4F3250AB.4060307@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-chat.all@tools.ietf.org" , Transport Directorate , "tsv-area@ietf.org" , Simple WG , The IESG Subject: Re: [Simple] tsv-dir review of draft-ietf-simple-chat-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 06:51:23 -0000 Your proposal sounds reasonable. Thanks. /Miguel On 13/02/2012 21:30, Cullen Jennings wrote: > > On Feb 8, 2012, at 3:38 AM, Miguel A. Garcia wrote: > >> Hi Cullen, >> >> Thanks for your review. See inline comments. >> >> On 07/02/2012 18:43, Cullen Jennings wrote: >> >>> Consider the case of a chat room that is receiving messages at a rate >>> of 10 per second (perhaps bad-attitude during the IESG plenary) and >>> also has some clients in the chat room that can only receiving >>> messages at a maximum rate of 5 per second ( perhaps an iphone via VPN >>> over 2G). Section 6.1 does not say what should happen in this case. >> >> I understand the problem description. The question is whether we want to make the application layer aware of potential congestion and take actions on it. >> >> I don't know how the chat room application could in the first place detect congestion. Any ideas of what to write in the draft are highly appreciated. > > Note - I'd be OK with publishing the document with no change but I think some text would improve the draft. > > I think the most important part is just point out that this is a problem and applications need to have a strategy to deal with it. I would not prescribe a strategy that apps had to implement but instead have some non normative strategies that an application might use. One strategy is that is any client falls more than 10 seconds behind, that client get disconnected. > > > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ben@estacado.net Mon Feb 13 22:57:47 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE14E21E800F for ; Mon, 13 Feb 2012 22:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvPuzYqr7oQ3 for ; Mon, 13 Feb 2012 22:57:47 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 302F721E8039 for ; Mon, 13 Feb 2012 22:57:47 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q1E6vcaI016788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Feb 2012 00:57:43 -0600 (CST) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: <4F3A001F.5060404@ericsson.com> Date: Tue, 14 Feb 2012 00:57:38 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <4F322E09.2020801@ericsson.com> <1295910B-9B83-4829-B308-CC921B73D147@ag-projects.com> <4F339146.4030609@ericsson.com> <709DBF9A-FCB7-4852-86D7-3BD1DADF6EA1@ag-projects.com> <81C46F45-F71F-4F7F-9A5B-5FCCD9C4B7FF@estacado.net> <808CE579-DB82-42D0-B023-B34AF17F650A@estacado.net> <4F39253F.7050204@ericsson.com> <2526CD8D-CEFF-447E-B432-AEE09F6C514D@estacado.net> <4F3A001F.5060404@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1257) Cc: Simple WG Subject: Re: [Simple] SIMPLE chat: Status codes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 06:57:48 -0000 On Feb 14, 2012, at 12:33 AM, Miguel A. Garcia wrote: > hmmm... I agree with you Ben, the existing 403 code has the same semantics. > > So, let's revise the proposal. List of new codes used by the draft: > > 404 Failure to resolve recipient's URI > 424 Malformed nickname > 425 Nickname reserved or already in use > 428 Private messages not supported > > Usage of existing codes: > > 403 Not allowed > wfm Thanks! Ben. From saul@ag-projects.com Tue Feb 14 01:10:17 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4937721F863C for ; Tue, 14 Feb 2012 01:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4FY4pYx2GrR for ; Tue, 14 Feb 2012 01:10:16 -0800 (PST) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id AA6BD21F863B for ; Tue, 14 Feb 2012 01:10:16 -0800 (PST) Received: by mail.sipthor.net (Postfix, from userid 5001) id ABA19B01B4; Tue, 14 Feb 2012 10:10:14 +0100 (CET) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 25522B019B; Tue, 14 Feb 2012 10:10:14 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <4F3A001F.5060404@ericsson.com> Date: Tue, 14 Feb 2012 10:10:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <59943EFB-13CE-4CA1-9088-3DDB3CEB1101@ag-projects.com> References: <4F322E09.2020801@ericsson.com> <1295910B-9B83-4829-B308-CC921B73D147@ag-projects.com> <4F339146.4030609@ericsson.com> <709DBF9A-FCB7-4852-86D7-3BD1DADF6EA1@ag-projects.com> <81C46F45-F71F-4F7F-9A5B-5FCCD9C4B7FF@estacado.net> <808CE579-DB82-42D0-B023-B34AF17F650A@estacado.net> <4F39253F.7050204@ericsson.com> <2526CD8D-CEFF-447E-B432-AEE09F6C514D@estacado.net> <4F3A001F.5060404@ericsson.com> To: Miguel A. Garcia X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] SIMPLE chat: Status codes X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 09:10:17 -0000 On Feb 14, 2012, at 7:33 AM, Miguel A. Garcia wrote: > hmmm... I agree with you Ben, the existing 403 code has the same = semantics. >=20 > So, let's revise the proposal. List of new codes used by the draft: >=20 > 404 Failure to resolve recipient's URI > 424 Malformed nickname > 425 Nickname reserved or already in use > 428 Private messages not supported >=20 > Usage of existing codes: >=20 > 403 Not allowed >=20 +1, the new semantics for 425 covers the case I mentioned before and = using 403 instead of 507 also seems fine. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From miguel.a.garcia@ericsson.com Tue Feb 14 03:49:45 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9711E21F86F3 for ; Tue, 14 Feb 2012 03:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.312 X-Spam-Level: X-Spam-Status: No, score=-10.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1dMv4aAa5-s for ; Tue, 14 Feb 2012 03:49:45 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B97D721F873B for ; Tue, 14 Feb 2012 03:49:44 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-44-4f3a4a57f4d8 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 22.1C.27041.75A4A3F4; Tue, 14 Feb 2012 12:49:43 +0100 (CET) Received: from [159.107.24.207] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Tue, 14 Feb 2012 12:49:43 +0100 Message-ID: <4F3A4A56.8060502@ericsson.com> Date: Tue, 14 Feb 2012 12:49:42 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Simple WG , Cullen Jennings Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [Simple] SIMPLE chat: Proposal to address congestion X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 11:49:45 -0000 According to Cullen, the SIMPLE chat draft should say something to address congestion. This is not an area of my expertise, so I may have something wrong. But let me give it a try. My proposal is to add one more section, 6.4, to address congestion. Please comment and propose changes to the text if you are not satisfied. 6.4. Congestion Avoidance Congestion can occur when multiple heterogeneous interfaces are used by a diversity of users who are participating in a chat room. Some of these users might have fast path capable of high throughputs while other users might be slow paths with constrained throughputs. It is therefore possible that a subset of the participants of the chat room are able to send and receive messages at a high rate or with large contents (e.g., pictures), whereas others are not able to keep the pace. Additionally, since MSRP uses a connection-oriented transport protocol such as TCP, it is expected that the TCP congestion avoidance mechanisms will also be activated should congestion occur. While this document does not mandate a particular MSRP-specific mechanism to avoid congestion in any of the paths, something that is deemed outside the scope of this document, this document provides some recommendations for implementors to consider. It is RECOMMENDED that MSRP switches implement one or more MSRP- specific strategies to detect and avoid congestion. Possible strategies (but definitely not a comprehensive list) include: o If the MSRP switch is writing data to a send buffer and detects that the send buffer associated to that TCP connection is getting full (e.g., close to 80% of its capacity), the MSRP switch marks the associated MSRP sessions making use of that TCP connection as "congested". o Prior to sending a new MSRP message to a user, the MSRP switch verifies the congested flag associated to that MSRP session. If the MSRP session is marked as congested, the MSRP switch can apply a congestion avoidance mechanism, such as: * The MSRP switch can discard regular MSRP messages sent to that user while the TCP send buffer is congested. In order to inform the user of the congestion, the MSRP switch can send a regular MSRP message indicating the user that some messages are discarded due to network congestion. * The MSRP can implement a temporary policy to disallow the distribution of messages larger than a certain size to MSRP sessions marked as congested. Similarly, the user should be inform of this fact by the MSRP switch sending a regular MSRP message indicating this condition. -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From wwwrun@rfc-editor.org Tue Feb 14 13:59:23 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2C821E80D3 for ; Tue, 14 Feb 2012 13:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4jM8V92CsS5 for ; Tue, 14 Feb 2012 13:59:22 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2CD21E80CA for ; Tue, 14 Feb 2012 13:59:22 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id F2F5172F1F1; Tue, 14 Feb 2012 13:54:39 -0800 (PST) To: hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com From: RFC Errata System Message-Id: <20120214215439.F2F5172F1F1@rfc-editor.org> Date: Tue, 14 Feb 2012 13:54:39 -0800 (PST) X-Mailman-Approved-At: Tue, 14 Feb 2012 14:35:19 -0800 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] [Technical Errata Reported] RFC4480 (3121) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 21:59:23 -0000 The following errata report has been submitted for RFC4480, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=3121 -------------------------------------- Type: Technical Reported by: Peter Saint-Andre Section: 7.2 Original Text ------------- Corrected Text -------------- Notes ----- Erratum #2959 claimed that the element "lunch" needs to be removed from the specification since it is not included in the schema. However, the schema was in error. This erratum corrects the schema so that, if approved, IANA can update the information at http://www.iana.org/assignments/xml-registry/schema/pidf/status/rpid.xsd Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4480 (draft-ietf-simple-rpid-10) -------------------------------------- Title : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) Publication Date : July 2006 Author(s) : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg Category : PROPOSED STANDARD Source : SIP for Instant Messaging and Presence Leveraging Extensions Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From rjsparks@nostrum.com Tue Feb 14 14:36:07 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B2321E8112; Tue, 14 Feb 2012 14:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UyUIQgmE1Cy; Tue, 14 Feb 2012 14:36:06 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9D72C21E8016; Tue, 14 Feb 2012 14:36:06 -0800 (PST) Received: from unexplicable.local (pool-71-170-125-181.dllstx.fios.verizon.net [71.170.125.181]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q1EMa57P092767 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 16:36:05 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F3AE1D5.5030505@nostrum.com> Date: Tue, 14 Feb 2012 16:36:05 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: rai@ietf.org, simple@ietf.org, geopriv@ietf.org References: <20120214215439.F2F5172F1F1@rfc-editor.org> In-Reply-To: <20120214215439.F2F5172F1F1@rfc-editor.org> X-Forwarded-Message-Id: <20120214215439.F2F5172F1F1@rfc-editor.org> Content-Type: multipart/mixed; boundary="------------010003050509010204040407" Received-SPF: pass (nostrum.com: 71.170.125.181 is authenticated by a trusted mechanism) Subject: [Simple] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rai@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 22:36:07 -0000 This is a multi-part message in MIME format. --------------010003050509010204040407 Content-Type: multipart/alternative; boundary="------------000804020103070702030009" --------------000804020103070702030009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This erratum will change the schema for RPID registered with IANA. (I've confirmed with IANA that they can handle a change made this way). There have been discussions in several groups about registry maintenance with some confusion about whether changes can be made to an existing schema. Our XML experts (Peter in this case) assure us that schema changes are OK. In most cases, I would ask that a change to a registration like this be done with a document. That's definitely required if we're doing anything more than correcting an obvious mistake. In this case, however, it is obvious that these values were intended to be included in the affected list from the beginning. I plan to approve this erratum a week from today. If you believe this is not the right thing to do, please speak now. RjS -------- Original Message -------- Subject: [Technical Errata Reported] RFC4480 (3121) Date: Tue, 14 Feb 2012 13:54:39 -0800 (PST) From: RFC Errata System To: hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com CC: stpeter@stpeter.im, simple@ietf.org, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC4480, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=3121 -------------------------------------- Type: Technical Reported by: Peter Saint-Andre Section: 7.2 Original Text ------------- Corrected Text -------------- Notes ----- Erratum #2959 claimed that the element "lunch" needs to be removed from the specification since it is not included in the schema. However, the schema was in error. This erratum corrects the schema so that, if approved, IANA can update the information at http://www.iana.org/assignments/xml-registry/schema/pidf/status/rpid.xsd Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4480 (draft-ietf-simple-rpid-10) -------------------------------------- Title : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) Publication Date : July 2006 Author(s) : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg Category : PROPOSED STANDARD Source : SIP for Instant Messaging and Presence Leveraging Extensions Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG --------------000804020103070702030009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This erratum will change the schema for RPID registered with IANA.
(I've confirmed with IANA that they can handle a change made this way).

There have been discussions in several groups about registry maintenance with some
confusion about whether changes can be made to an existing schema. Our XML experts
(Peter in this case) assure us that schema changes are OK.

In most cases, I would ask that a change to a registration like this be done with a document.
That's definitely required if we're doing anything more than correcting an obvious mistake.
In this case, however, it is obvious that these values were intended to be included in the
affected list from the beginning.

I plan to approve this erratum a week from today. If you believe this is not the right thing to do,
please speak now.

RjS


-------- Original Message --------
Subject: [Technical Errata Reported] RFC4480 (3121)
Date: Tue, 14 Feb 2012 13:54:39 -0800 (PST)
From: RFC Errata System <rfc-editor@rfc-editor.org>
To: hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com
CC: stpeter@stpeter.im, simple@ietf.org, rfc-editor@rfc-editor.org 


The following errata report has been submitted for RFC4480,
"RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=3121

--------------------------------------
Type: Technical
Reported by: Peter Saint-Andre <stpeter@stpeter.im>

Section: 7.2

Original Text
-------------
                 <xs:element name="looking-for-work"
                   type="empty" />
                 <xs:element name="meal"
                   type="empty" />

Corrected Text
--------------
                 <xs:element name="looking-for-work"
                   type="empty" />
                 <xs:element name="lunch"
                   type="empty" />
                 <xs:element name="meal"
                   type="empty" />

Notes
-----
Erratum #2959 claimed that the element "lunch" needs to be removed from the specification since it is not included in the schema. However, the schema was in error. This erratum corrects the schema so that, if approved, IANA can update the information at http://www.iana.org/assignments/xml-registry/schema/pidf/status/rpid.xsd

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4480 (draft-ietf-simple-rpid-10)
--------------------------------------
Title               : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)
Publication Date    : July 2006
Author(s)           : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg
Category            : PROPOSED STANDARD
Source              : SIP for Instant Messaging and Presence Leveraging Extensions
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
--------------000804020103070702030009-- --------------010003050509010204040407 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" --------------010003050509010204040407-- From ben@nostrum.com Tue Feb 14 14:38:51 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D598421F8567; Tue, 14 Feb 2012 14:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Vdmoq3u3iM9; Tue, 14 Feb 2012 14:38:50 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D03C621F8564; Tue, 14 Feb 2012 14:38:48 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q1EMclFV092966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Feb 2012 16:38:47 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_557CE07C-4775-46A4-AA9B-8E24EF1BF16F" From: Ben Campbell In-Reply-To: <4F3AE1D5.5030505@nostrum.com> Date: Tue, 14 Feb 2012 16:38:50 -0600 Message-Id: References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> To: rai@ietf.org X-Mailer: Apple Mail (2.1257) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: geopriv@ietf.org, simple@ietf.org Subject: Re: [Simple] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 22:38:52 -0000 --Apple-Mail=_557CE07C-4775-46A4-AA9B-8E24EF1BF16F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 14, 2012, at 4:36 PM, Robert Sparks wrote: > This erratum will change the schema for RPID registered with IANA.=20 > (I've confirmed with IANA that they can handle a change made this = way). >=20 > There have been discussions in several groups about registry = maintenance with some > confusion about whether changes can be made to an existing schema. Our = XML experts > (Peter in this case) assure us that schema changes are OK. >=20 > In most cases, I would ask that a change to a registration like this = be done with a document. > That's definitely required if we're doing anything more than = correcting an obvious mistake. > In this case, however, it is obvious that these values were intended = to be included in the=20 > affected list from the beginning. >=20 > I plan to approve this erratum a week from today. If you believe this = is not the right thing to do, > please speak now. >=20 While you didn't ask for concurring opinions: I concur with the = approach. > RjS >=20 >=20 > -------- Original Message -------- > Subject: [Technical Errata Reported] RFC4480 (3121) > Date: Tue, 14 Feb 2012 13:54:39 -0800 (PST) > From: RFC Errata System > To: hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, = jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, = ben@nostrum.com, hisham.khartabil@gmail.com > CC: stpeter@stpeter.im, simple@ietf.org, rfc-editor@rfc-editor.org >=20 > The following errata report has been submitted for RFC4480, > "RPID: Rich Presence Extensions to the Presence Information Data = Format (PIDF)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4480&eid=3D3121 >=20 > -------------------------------------- > Type: Technical > Reported by: Peter Saint-Andre >=20 > Section: 7.2 >=20 > Original Text > ------------- > type=3D"empty" /> > type=3D"empty" /> >=20 > Corrected Text > -------------- > type=3D"empty" /> > type=3D"empty" /> > type=3D"empty" /> >=20 > Notes > ----- > Erratum #2959 claimed that the element "lunch" needs to be removed = from the specification since it is not included in the schema. However, = the schema was in error. This erratum corrects the schema so that, if = approved, IANA can update the information at = http://www.iana.org/assignments/xml-registry/schema/pidf/status/rpid.xsd >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC4480 (draft-ietf-simple-rpid-10) > -------------------------------------- > Title : RPID: Rich Presence Extensions to the Presence = Information Data Format (PIDF) > Publication Date : July 2006 > Author(s) : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. = Rosenberg > Category : PROPOSED STANDARD > Source : SIP for Instant Messaging and Presence = Leveraging Extensions > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail=_557CE07C-4775-46A4-AA9B-8E24EF1BF16F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Feb 14, 2012, at 4:36 PM, Robert Sparks wrote:

This erratum will change the schema for RPID registered with IANA.
(I've confirmed with IANA that they can handle a change made this way).

There have been discussions in several groups about registry maintenance with some
confusion about whether changes can be made to an existing schema. Our XML experts
(Peter in this case) assure us that schema changes are OK.

In most cases, I would ask that a change to a registration like this be done with a document.
That's definitely required if we're doing anything more than correcting an obvious mistake.
In this case, however, it is obvious that these values were intended to be included in the
affected list from the beginning.

I plan to approve this erratum a week from today. If you believe this is not the right thing to do,
please speak now.


While you didn't ask for concurring opinions: I concur with the approach.


RjS


-------- Original Message --------
Subject: [Technical Errata Reported] RFC4480 (3121)
Date: Tue, 14 Feb 2012 13:54:39 -0800 (PST)
From: RFC Errata System <rfc-editor@rfc-editor.org>
To: hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com
CC: stpeter@stpeter.im, simple@ietf.org, rfc-editor@rfc-editor.org 


The following errata report has been submitted for RFC4480,
"RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=3121

--------------------------------------
Type: Technical
Reported by: Peter Saint-Andre <stpeter@stpeter.im>

Section: 7.2

Original Text
-------------
                 <xs:element name="looking-for-work"
                   type="empty" />
                 <xs:element name="meal"
                   type="empty" />

Corrected Text
--------------
                 <xs:element name="looking-for-work"
                   type="empty" />
                 <xs:element name="lunch"
                   type="empty" />
                 <xs:element name="meal"
                   type="empty" />

Notes
-----
Erratum #2959 claimed that the element "lunch" needs to be removed from the specification since it is not included in the schema. However, the schema was in error. This erratum corrects the schema so that, if approved, IANA can update the information at http://www.iana.org/assignments/xml-registry/schema/pidf/status/rpid.xsd

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4480 (draft-ietf-simple-rpid-10)
--------------------------------------
Title               : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)
Publication Date    : July 2006
Author(s)           : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg
Category            : PROPOSED STANDARD
Source              : SIP for Instant Messaging and Presence Leveraging Extensions
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
<Attached Message Part.txt>_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

--Apple-Mail=_557CE07C-4775-46A4-AA9B-8E24EF1BF16F-- From martin.thomson@gmail.com Tue Feb 14 15:08:55 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6CD21E80F5; Tue, 14 Feb 2012 15:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.892 X-Spam-Level: X-Spam-Status: No, score=-4.892 tagged_above=-999 required=5 tests=[AWL=-1.294, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwvvMBwbgMlP; Tue, 14 Feb 2012 15:08:54 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A370121E807F; Tue, 14 Feb 2012 15:08:51 -0800 (PST) Received: by bkuw12 with SMTP id w12so493107bku.31 for ; Tue, 14 Feb 2012 15:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PMxLIOSJXivwnja022a0GZ2F6Vje4w22ubo4ljwpSzI=; b=klaxe4Qi8zO56z1SwK3vaTt8aQq/UYpwvtCxhlzU2VYJfZwGIMHuNkRuFDzwB4lGbe 0LdmO8F3H8urP9bhmm2h1iU085UZnmJoLpv6filS9NL+2HvosTdzEs7RTcvmL5DLVe15 4lwDe/VzhAMOD+F+sXF8rtsFYKBj76pw6F/Ww= MIME-Version: 1.0 Received: by 10.204.141.9 with SMTP id k9mr10167291bku.93.1329260930673; Tue, 14 Feb 2012 15:08:50 -0800 (PST) Received: by 10.204.241.81 with HTTP; Tue, 14 Feb 2012 15:08:50 -0800 (PST) In-Reply-To: <4F3AE1D5.5030505@nostrum.com> References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> Date: Tue, 14 Feb 2012 15:08:50 -0800 Message-ID: From: Martin Thomson To: rai@ietf.org Content-Type: multipart/alternative; boundary=0015175d6826962bcf04b8f4ad31 Cc: geopriv@ietf.org, simple@ietf.org Subject: Re: [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 23:08:55 -0000 --0015175d6826962bcf04b8f4ad31 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Since the extension point in the existing schema is marked ##other and lax, a processor with an old schema will reject an instance document that contains the "unknown" {urn:ietf:params:xml:ns:pidf:rpid}:lunch element. That's a backwards compatibility break. --Martin On 14 February 2012 14:36, Robert Sparks wrote: > This erratum will change the schema for RPID registered with IANA. > (I've confirmed with IANA that they can handle a change made this way). > > There have been discussions in several groups about registry maintenance > with some > confusion about whether changes can be made to an existing schema. Our XM= L > experts > (Peter in this case) assure us that schema changes are OK. > > In most cases, I would ask that a change to a registration like this be > done with a document. > That's definitely required if we're doing anything more than correcting a= n > obvious mistake. > In this case, however, it is obvious that these values were intended to b= e > included in the > affected list from the beginning. > > I plan to approve this erratum a week from today. If you believe this is > not the right thing to do, > please speak now. > > RjS > > > -------- Original Message -------- Subject: [Technical Errata Reported] > RFC4480 (3121) Date: Tue, 14 Feb 2012 13:54:39 -0800 (PST) From: RFC > Errata System To= : > hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyzivat@cisco.com, > jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, > ben@nostrum.com, hisham.khartabil@gmail.com CC: stpeter@stpeter.im, > simple@ietf.org, rfc-editor@rfc-editor.org > > The following errata report has been submitted for RFC4480, > "RPID: Rich Presence Extensions to the Presence Information Data Format (= PIDF)". > > -------------------------------------- > You may review the report below and at:http://www.rfc-editor.org/errata_s= earch.php?rfc=3D4480&eid=3D3121 > > -------------------------------------- > Type: Technical > Reported by: Peter Saint-Andre > > Section: 7.2 > > Original Text > ------------- > type=3D"empty" /> > type=3D"empty" /> > > Corrected Text > -------------- > type=3D"empty" /> > type=3D"empty" /> > type=3D"empty" /> > > Notes > ----- > Erratum #2959 claimed that the element "lunch" needs to be removed from t= he specification since it is not included in the schema. However, the schem= a was in error. This erratum corrects the schema so that, if approved, IANA= can update the information at http://www.iana.org/assignments/xml-registry= /schema/pidf/status/rpid.xsd > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4480 (draft-ietf-simple-rpid-10) > -------------------------------------- > Title : RPID: Rich Presence Extensions to the Presence Info= rmation Data Format (PIDF) > Publication Date : July 2006 > Author(s) : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenber= g > Category : PROPOSED STANDARD > Source : SIP for Instant Messaging and Presence Leveraging E= xtensions > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > > --0015175d6826962bcf04b8f4ad31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Since the extension point in the existing schema is marked ##other and lax,= a processor with an old schema will reject an instance document that conta= ins the "unknown" {urn:ietf:params:xml:ns:pidf:rpid}:lunch elemen= t.

That's a backwards compatibility break.

--Martin

On 1= 4 February 2012 14:36, Robert Sparks <rjsparks@nostrum.com> wrote:
=20 =20 =20
This erratum will change the schema for RPID registered with IANA.
(I've confirmed with IANA that they can handle a change made this way).

There have been discussions in several groups about registry maintenance with some
confusion about whether changes can be made to an existing schema. Our XML experts
(Peter in this case) assure us that schema changes are OK.

In most cases, I would ask that a change to a registration like this be done with a document.
That's definitely required if we're doing anything more than correcting an obvious mistake.
In this case, however, it is obvious that these values were intended to be included in the
affected list from the beginning.

I plan to approve this erratum a week from today. If you believe this is not the right thing to do,
please speak now.

RjS


-------- Original Message --------
Subject: [Technical Errata Reported] RFC4480 (3121)
Date: Tue, 14 Feb 2012 13:54:39 -0800 (PST)
From: RFC Errata System <rfc-editor@rfc-editor.org>
To: hgs+simple@cs.columbia.edu, vkg@lucent.com, pkyziva= t@cisco.com, jdr= osen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostru= m.com, = hisham.khartabil@gmail.com
CC: stpet= er@stpeter.im, sim= ple@ietf.org, = rfc-editor@rfc-editor.org 


The following errata report has been submitted for RFC4480,
"RPID: Rich Presence Extensions to the Presence Information Data Forma=
t (PIDF)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=
=3D4480&eid=3D3121

--------------------------------------
Type: Technical
Reported by: Peter Saint-Andre <stpeter@stpeter.im>

Section: 7.2

Original Text
-------------
                 <xs:element name=3D"looking-for-work"
                   type=3D"empty" />
                 <xs:element name=3D"meal"
                   type=3D"empty" />

Corrected Text
--------------
                 <xs:element name=3D"looking-for-work"
                   type=3D"empty" />
                 <xs:element name=3D"lunch"
                   type=3D"empty" />
                 <xs:element name=3D"meal"
                   type=3D"empty" />

Notes
-----
Erratum #2959 claimed that the element "lunch" needs to be remove=
d from the specification since it is not included in the schema. However, t=
he schema was in error. This erratum corrects the schema so that, if approv=
ed, IANA can update the information at http://w=
ww.iana.org/assignments/xml-registry/schema/pidf/status/rpid.xsd

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea=
se
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.=20

--------------------------------------
RFC4480 (draft-ietf-simple-rpid-10)
--------------------------------------
Title               : RPID: Rich Presence Extensions to the Presence Inform=
ation Data Format (PIDF)
Publication Date    : July 2006
Author(s)           : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg
Category            : PROPOSED STANDARD
Source              : SIP for Instant Messaging and Presence Leveraging Ext=
ensions
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv


--0015175d6826962bcf04b8f4ad31-- From stpeter@stpeter.im Thu Feb 16 09:58:30 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9946221F87D3; Thu, 16 Feb 2012 09:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9s+yoilypi3k; Thu, 16 Feb 2012 09:58:26 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1D75E21F87D8; Thu, 16 Feb 2012 09:58:25 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3AE6540058; Thu, 16 Feb 2012 11:09:20 -0700 (MST) Message-ID: <4F3D43C0.2040005@stpeter.im> Date: Thu, 16 Feb 2012 10:58:24 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Martin Thomson References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org, rai@ietf.org, simple@ietf.org Subject: Re: [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:58:30 -0000 Naturally, it would make sense to check with current implementers. In particular, is anyone doing schema validation? On 2/14/12 4:08 PM, Martin Thomson wrote: > Since the extension point in the existing schema is marked ##other and > lax, a processor with an old schema will reject an instance document > that contains the "unknown" {urn:ietf:params:xml:ns:pidf:rpid}:lunch > element. > > That's a backwards compatibility break. > > --Martin > > On 14 February 2012 14:36, Robert Sparks > wrote: > > This erratum will change the schema for RPID registered with IANA. > (I've confirmed with IANA that they can handle a change made this way). > > There have been discussions in several groups about registry > maintenance with some > confusion about whether changes can be made to an existing schema. > Our XML experts > (Peter in this case) assure us that schema changes are OK. > > In most cases, I would ask that a change to a registration like this > be done with a document. > That's definitely required if we're doing anything more than > correcting an obvious mistake. > In this case, however, it is obvious that these values were intended > to be included in the > affected list from the beginning. > > I plan to approve this erratum a week from today. If you believe > this is not the right thing to do, > please speak now. > > RjS > > > -------- Original Message -------- > Subject: [Technical Errata Reported] RFC4480 (3121) > Date: Tue, 14 Feb 2012 13:54:39 -0800 (PST) > From: RFC Errata System > > To: hgs+simple@cs.columbia.edu , > vkg@lucent.com , pkyzivat@cisco.com > , jdrosen@cisco.com > , gonzalo.camarillo@ericsson.com > , rjsparks@nostrum.com > , ben@nostrum.com > , hisham.khartabil@gmail.com > > CC: stpeter@stpeter.im , simple@ietf.org > , rfc-editor@rfc-editor.org > > > > > The following errata report has been submitted for RFC4480, > "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=3121 > > -------------------------------------- > Type: Technical > Reported by: Peter Saint-Andre > > Section: 7.2 > > Original Text > ------------- > type="empty" /> > type="empty" /> > > Corrected Text > -------------- > type="empty" /> > type="empty" /> > type="empty" /> > > Notes > ----- > Erratum #2959 claimed that the element "lunch" needs to be removed from the specification since it is not included in the schema. However, the schema was in error. This erratum corrects the schema so that, if approved, IANA can update the information at http://www.iana.org/assignments/xml-registry/schema/pidf/status/rpid.xsd > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4480 (draft-ietf-simple-rpid-10) > -------------------------------------- > Title : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) > Publication Date : July 2006 > Author(s) : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg > Category : PROPOSED STANDARD > Source : SIP for Instant Messaging and Presence Leveraging Extensions > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From saul@ag-projects.com Thu Feb 16 10:11:59 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5FC21F87FD; Thu, 16 Feb 2012 10:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 226VFXmwQk5F; Thu, 16 Feb 2012 10:11:58 -0800 (PST) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB3A21F87F9; Thu, 16 Feb 2012 10:11:58 -0800 (PST) Received: by mail.sipthor.net (Postfix, from userid 5001) id 215F7B01A4; Thu, 16 Feb 2012 19:11:56 +0100 (CET) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 75D31B01A2; Thu, 16 Feb 2012 19:11:44 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <4F3D43C0.2040005@stpeter.im> Date: Thu, 16 Feb 2012 19:11:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> <4F3D43C0.2040005@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) Cc: geopriv@ietf.org, rai@ietf.org, simple@ietf.org Subject: Re: [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:11:59 -0000 Hi, On Feb 16, 2012, at 6:58 PM, Peter Saint-Andre wrote: > Naturally, it would make sense to check with current implementers. In > particular, is anyone doing schema validation? >=20 We are currently doing schema validation both on the server side = (OpenXCAP, for pidf-manipulation) and client side (SIPSIMPLE SDK). I didn't check the details of the errata, but if it's reasonable I guess = we could see if we can workaround it for a while and make the switch = after a reasonable amount of time. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From hannes.tschofenig@gmx.net Thu Feb 16 10:26:25 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4810C21F85F6 for ; Thu, 16 Feb 2012 10:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4Aa4W4AA2sq for ; Thu, 16 Feb 2012 10:26:21 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E25DC21F8656 for ; Thu, 16 Feb 2012 10:26:20 -0800 (PST) Received: (qmail invoked by alias); 16 Feb 2012 18:26:19 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp033) with SMTP; 16 Feb 2012 19:26:19 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+HmtAr5sKHdrVDCRjLy4ZoHJ/0E0Vc9LUvoQnYj4 x5CofKZL7x8cg/ Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: <088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> Date: Thu, 16 Feb 2012 20:26:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> <4F3D43C0.2040005@stpeter.im> <088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: geopriv@ietf.org, rai@ietf.org, simple@ietf.org Subject: Re: [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:26:25 -0000 I am curious: Why you do schema validation? When you receive a PIDF document in a SIP message then you will have to = parse it. Since we put any namespace=3D"##other" statements in nearly = all our schema files I am curious what you actually going to learn from = the validation since almost everything validates without error.=20 On Feb 16, 2012, at 8:11 PM, Sa=FAl Ibarra Corretg=E9 wrote: > Hi, >=20 > On Feb 16, 2012, at 6:58 PM, Peter Saint-Andre wrote: >=20 >> Naturally, it would make sense to check with current implementers. In >> particular, is anyone doing schema validation? >>=20 >=20 > We are currently doing schema validation both on the server side = (OpenXCAP, for pidf-manipulation) and client side (SIPSIMPLE SDK). >=20 > I didn't check the details of the errata, but if it's reasonable I = guess we could see if we can workaround it for a while and make the = switch after a reasonable amount of time. >=20 >=20 > Regards, >=20 > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects >=20 >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From martin.thomson@gmail.com Thu Feb 16 11:38:57 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6491A21F8817; Thu, 16 Feb 2012 11:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.833 X-Spam-Level: X-Spam-Status: No, score=-4.833 tagged_above=-999 required=5 tests=[AWL=-1.234, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YU0itTwN-xuA; Thu, 16 Feb 2012 11:38:56 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 449C721F8811; Thu, 16 Feb 2012 11:38:55 -0800 (PST) Received: by bkuw12 with SMTP id w12so2646704bku.31 for ; Thu, 16 Feb 2012 11:38:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L58NCRXHK4xHKh/cvZik0TxKzaDeL3sg/8T/vZP9W2E=; b=gDbcz3hIGat99HTHuA3gn7POFgGmj7wxglaQ5Uc3/p5q/vQnIRoSqDo1Vq4UQnjzNT ViqX4QaFsbu7z4OwUuUPzNKvI16hgYYcDlnI4u7gqG7F81asFeEUFojzcC6IxY/XzHh/ feoYq+vO1a/jqX60f/dqVU0TeTvmy/hc2PvxE= MIME-Version: 1.0 Received: by 10.205.125.12 with SMTP id gq12mr2493763bkc.39.1329421134354; Thu, 16 Feb 2012 11:38:54 -0800 (PST) Received: by 10.204.241.81 with HTTP; Thu, 16 Feb 2012 11:38:54 -0800 (PST) In-Reply-To: <4F3D43C0.2040005@stpeter.im> References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> <4F3D43C0.2040005@stpeter.im> Date: Thu, 16 Feb 2012 11:38:54 -0800 Message-ID: From: Martin Thomson To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: geopriv@ietf.org, rai@ietf.org, simple@ietf.org Subject: Re: [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:38:57 -0000 On 16 February 2012 09:58, Peter Saint-Andre wrote: > Naturally, it would make sense to check with current implementers. In > particular, is anyone doing schema validation? ...and who is using RPID? The intersection of those sets is probably small, possibly empty. And you want empty (or to exclude those who are willing to make a minor patch). I know that schema validation was the default mode of operation where I used to work. RPID was not. Sounds like more than an erratum's worth of work to me. Do you have a problem with noting the existence of the problem without specifying a remedy? From pkyzivat@alum.mit.edu Thu Feb 16 11:49:35 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0CF21E809D for ; Thu, 16 Feb 2012 11:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqihnX7rE9b7 for ; Thu, 16 Feb 2012 11:49:27 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 7834521E807B for ; Thu, 16 Feb 2012 11:49:27 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by QMTA11.westchester.pa.mail.comcast.net with comcast id ajiK1i01B1wpRvQ5BjpUmM; Thu, 16 Feb 2012 19:49:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([140.242.210.2]) by omta18.westchester.pa.mail.comcast.net with comcast id ajpJ1i00q03fLrQ3ejpMiB; Thu, 16 Feb 2012 19:49:26 +0000 Message-ID: <4F3D5DBD.2040303@alum.mit.edu> Date: Thu, 16 Feb 2012 14:49:17 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: simple@ietf.org References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> <4F3D43C0.2040005@stpeter.im> <088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:49:35 -0000 On 2/16/12 1:26 PM, Hannes Tschofenig wrote: > I am curious: Why you do schema validation? > > When you receive a PIDF document in a SIP message then you will have to parse it. Since we put any namespace="##other" statements in nearly all our schema files I am curious what you actually going to learn from the validation since almost everything validates without error. Uhhh - to detect changes like this one? :-) > On Feb 16, 2012, at 8:11 PM, Saúl Ibarra Corretgé wrote: > >> Hi, >> >> On Feb 16, 2012, at 6:58 PM, Peter Saint-Andre wrote: >> >>> Naturally, it would make sense to check with current implementers. In >>> particular, is anyone doing schema validation? >>> >> >> We are currently doing schema validation both on the server side (OpenXCAP, for pidf-manipulation) and client side (SIPSIMPLE SDK). >> >> I didn't check the details of the errata, but if it's reasonable I guess we could see if we can workaround it for a while and make the switch after a reasonable amount of time. >> >> >> Regards, >> >> -- >> Saúl Ibarra Corretgé >> AG Projects >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From martin.thomson@gmail.com Thu Feb 16 13:29:10 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC43621E808E for ; Thu, 16 Feb 2012 13:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.79 X-Spam-Level: X-Spam-Status: No, score=-4.79 tagged_above=-999 required=5 tests=[AWL=-1.191, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAkZbijamLvj for ; Thu, 16 Feb 2012 13:29:10 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50B8B21E8040 for ; Thu, 16 Feb 2012 13:29:04 -0800 (PST) Received: by bkuw12 with SMTP id w12so2781688bku.31 for ; Thu, 16 Feb 2012 13:29:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KN93He4ZGn7TEF59up3SfwntBdfdyfU/kUfhZLg2ZuY=; b=dUQ/8y5+JPzzbkl0FQUfTDnet0tbMjqnPmjiiDdCAVvj+QZe2xUVfr3dTBhtYMlK4p 0bkhCNHwawXpURT2lfmE3mxsEnRixkK3nT86F8fTY9vOmRkGRIuA4IIJOLBiOGZgQRA9 fn5wkRoytlK32YjVPDtOqYxNKvC7aA6XvW1/A= MIME-Version: 1.0 Received: by 10.204.156.213 with SMTP id y21mr2907567bkw.21.1329427743259; Thu, 16 Feb 2012 13:29:03 -0800 (PST) Received: by 10.204.241.81 with HTTP; Thu, 16 Feb 2012 13:29:03 -0800 (PST) In-Reply-To: <4F3D5DBD.2040303@alum.mit.edu> References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> <4F3D43C0.2040005@stpeter.im> <088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> <4F3D5DBD.2040303@alum.mit.edu> Date: Thu, 16 Feb 2012 13:29:03 -0800 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: simple@ietf.org Subject: Re: [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 21:29:10 -0000 On 16 February 2012 11:49, Paul Kyzivat wrote: > On 2/16/12 1:26 PM, Hannes Tschofenig wrote: >> >> I am curious: Why you do schema validation? > > Uhhh - to detect changes like this one? :-) Or to detect random, valid gibberish in the stream. Unknown elements and attributes; bad cardinality; invalid lexical representations of text; etc... --Martin From toyvenu@gmail.com Mon Feb 20 00:10:35 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D2621F855B for ; Mon, 20 Feb 2012 00:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5IuxwkXAWD5 for ; Mon, 20 Feb 2012 00:10:35 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B60D521F8484 for ; Mon, 20 Feb 2012 00:10:34 -0800 (PST) Received: by lahl5 with SMTP id l5so6895951lah.31 for ; Mon, 20 Feb 2012 00:10:33 -0800 (PST) Received-SPF: pass (google.com: domain of toyvenu@gmail.com designates 10.112.103.228 as permitted sender) client-ip=10.112.103.228; Authentication-Results: mr.google.com; spf=pass (google.com: domain of toyvenu@gmail.com designates 10.112.103.228 as permitted sender) smtp.mail=toyvenu@gmail.com; dkim=pass header.i=toyvenu@gmail.com Received: from mr.google.com ([10.112.103.228]) by 10.112.103.228 with SMTP id fz4mr6768021lbb.99.1329725433755 (num_hops = 1); Mon, 20 Feb 2012 00:10:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=wG4FUC5GLQZYmpmnwKYApXonO1wyNGnCajwDHeO9dvI=; b=WiXGXnnYbfZH+tVnwEwkpD4ifb5M0QAYYioJMmAahX49En9c58wvEiRrJetPf5BPiS +0d55oVjw3zSxv4oaFRsSilyEiTPcbHPu5bZF0DU+DBqS+WH6KnOinbwgy6BjY4nkOiY rjAr50RXDUWb/vtFjXBil2XvjadYzdfAb4GH4= MIME-Version: 1.0 Received: by 10.112.103.228 with SMTP id fz4mr5623190lbb.99.1329725433692; Mon, 20 Feb 2012 00:10:33 -0800 (PST) Received: by 10.152.122.239 with HTTP; Mon, 20 Feb 2012 00:10:33 -0800 (PST) Date: Mon, 20 Feb 2012 13:40:33 +0530 Message-ID: From: venu Y To: simple@ietf.org Content-Type: multipart/alternative; boundary=f46d040170711fc43a04b960d43d Subject: [Simple] Multiple m= lines X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 08:10:35 -0000 --f46d040170711fc43a04b960d43d Content-Type: text/plain; charset=ISO-8859-1 Hi all, Case: Client A wants to offer two file transfers(two m= lines) using MSRP in an SIP session with client B. Client B, on receiving the offer, displays the two file names with options (Accept/Reject) to user and waits for his response. If the user, accepts first file and didn't inform any thing about second file... then how should Client B should respond? 1. Should he force the user to give response to all offers at a time.. 2. Should he wait for a stipulated time, if no response is received from user, then he should opt for a default configured behaviour. 3. Is there any provision in offer/answer model, to inform the other party that.. one m= line status is ready and other m= line decision is in pending... As per SIP protocol, 200 O.K should be given with in 32 seconds. Thanks for your time. -- With Regards Venu toyvenu@gmail.com --f46d040170711fc43a04b960d43d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Case: Client A wants to offer two file transfers= (two m=3D lines) using MSRP in an SIP session with client B.

=
Client B, on receiving the offer, displays the two file names wi= th options (Accept/Reject) to user and waits for his response.

If the user, accepts first file and didn't inform a= ny thing about second file... then how should Client B should respond?

1. Should he force the user to give response to all of= fers at a time..

2. Should he wait for a stipulated time, if no response= is received from user, then he should opt for a default configured behavio= ur.

3. Is there any provision in offer/answer mode= l, to inform the other party that..=A0

one m=3D line status is ready and other m=3D line decis= ion is in pending...

As per SIP protocol, 200 O.K = should be given with in 32 seconds.

Thanks fo= r your time.

--
With Regards
Venu

--f46d040170711fc43a04b960d43d-- From ibc@aliax.net Mon Feb 20 01:07:13 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2360E21F86FF for ; Mon, 20 Feb 2012 01:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31wbWwyjhfkl for ; Mon, 20 Feb 2012 01:07:11 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D7D4F21F86FC for ; Mon, 20 Feb 2012 01:07:09 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so3965157vcb.31 for ; Mon, 20 Feb 2012 01:07:09 -0800 (PST) Received-SPF: pass (google.com: domain of ibc@aliax.net designates 10.220.156.201 as permitted sender) client-ip=10.220.156.201; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ibc@aliax.net designates 10.220.156.201 as permitted sender) smtp.mail=ibc@aliax.net Received: from mr.google.com ([10.220.156.201]) by 10.220.156.201 with SMTP id y9mr5265552vcw.22.1329728829399 (num_hops = 1); Mon, 20 Feb 2012 01:07:09 -0800 (PST) Received: by 10.220.156.201 with SMTP id y9mr4124282vcw.22.1329728829287; Mon, 20 Feb 2012 01:07:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.203.2 with HTTP; Mon, 20 Feb 2012 01:06:49 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 Feb 2012 10:06:49 +0100 Message-ID: To: venu Y Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlEQJJUktSJtxRAkxH17IgVfLQdT8arKOSXoXGkQJAjlrKW4gE7z+/geWbT8pedhQOe+wt3 Cc: simple@ietf.org Subject: Re: [Simple] Multiple m= lines X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 09:07:13 -0000 2012/2/20 venu Y : > As per SIP protocol, 200 O.K should be given with in 32 seconds. Not true. MSRP is offered within an INVITE so there is "no limit" (other than the "Expires" value in the INVITE when present, or the max time the UAC or UAS allows during ringing/progress state). --=20 I=C3=B1aki Baz Castillo From saul@ag-projects.com Mon Feb 20 01:07:52 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606E221F86FE; Mon, 20 Feb 2012 01:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9nj2pDAPB0J; Mon, 20 Feb 2012 01:07:52 -0800 (PST) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id C363B21F86FC; Mon, 20 Feb 2012 01:07:51 -0800 (PST) Received: by mail.sipthor.net (Postfix, from userid 5001) id 2CFF0B01B7; Mon, 20 Feb 2012 10:07:50 +0100 (CET) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 86BBEB019B; Mon, 20 Feb 2012 10:07:49 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Mon, 20 Feb 2012 10:07:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <042B7D73-556C-41AB-AC54-E59942D7575C@ag-projects.com> References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> <4F3D43C0.2040005@stpeter.im> <088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1084) Cc: geopriv@ietf.org, rai@ietf.org, simple@ietf.org Subject: Re: [Simple] [Geopriv] PLEASE TAKE NOTE: Fwd: [Technical Errata Reported] RFC4480 (3121) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 09:07:52 -0000 Hi, On Feb 16, 2012, at 7:26 PM, Hannes Tschofenig wrote: > I am curious: Why you do schema validation? >=20 > When you receive a PIDF document in a SIP message then you will have = to parse it. Since we put any namespace=3D"##other" statements in nearly = all our schema files I am curious what you actually going to learn from = the validation since almost everything validates without error.=20 >=20 Well, I like to do schema validation to al least know that the document = doesn't violate the specified structure. Yes, you may put whatever you = want in ##other, but PIDF does define certain elements, and those will = not fall in the ##other bucket, so those should be validated. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Mon Feb 20 01:13:20 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316D421F86F8 for ; Mon, 20 Feb 2012 01:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtnfKh6NAFEd for ; Mon, 20 Feb 2012 01:13:19 -0800 (PST) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id B16A421F8712 for ; Mon, 20 Feb 2012 01:13:08 -0800 (PST) Received: by mail.sipthor.net (Postfix, from userid 5001) id 65866B01B7; Mon, 20 Feb 2012 10:12:50 +0100 (CET) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id ABEC1B019B; Mon, 20 Feb 2012 10:12:49 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Mon, 20 Feb 2012 10:12:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <90BEEA9D-5BC2-4F2F-AF1F-6777074814FB@ag-projects.com> References: To: venu Y X-Mailer: Apple Mail (2.1084) Cc: simple@ietf.org Subject: Re: [Simple] Multiple m= lines X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 09:13:20 -0000 Hi, On Feb 20, 2012, at 9:10 AM, venu Y wrote: > Hi all, >=20 > Case: Client A wants to offer two file transfers(two m=3D lines) using = MSRP in an SIP session with client B. >=20 > Client B, on receiving the offer, displays the two file names with = options (Accept/Reject) to user and waits for his response. >=20 > If the user, accepts first file and didn't inform any thing about = second file... then how should Client B should respond? >=20 What do you mean by "didn't inform anything"? How does that 200 OK look = like? > 1. Should he force the user to give response to all offers at a time.. >=20 Of course, when you send the 200 OK all offered streams must be present = in the answer, if you want to reject a stream just set the port to 0. > 2. Should he wait for a stipulated time, if no response is received = from user, then he should opt for a default configured behaviour. >=20 > 3. Is there any provision in offer/answer model, to inform the other = party that..=20 >=20 > one m=3D line status is ready and other m=3D line decision is in = pending... >=20 I don't think that's possible. What you could do, for example, is learn = the information (filename, hash, size) on the stream you don't want to = accept right now, reject it and send a re-INVITE later, adding a new = stream with that data and direction 'recvonly', thus *requesting* that = the remote party sends you that file. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From toyvenu@gmail.com Mon Feb 20 01:33:13 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBED721F871D for ; Mon, 20 Feb 2012 01:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTacKfE6QYvG for ; Mon, 20 Feb 2012 01:33:12 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7036B21F871B for ; Mon, 20 Feb 2012 01:33:11 -0800 (PST) Received: by lahl5 with SMTP id l5so6993207lah.31 for ; Mon, 20 Feb 2012 01:33:10 -0800 (PST) Received-SPF: pass (google.com: domain of toyvenu@gmail.com designates 10.152.112.132 as permitted sender) client-ip=10.152.112.132; Authentication-Results: mr.google.com; spf=pass (google.com: domain of toyvenu@gmail.com designates 10.152.112.132 as permitted sender) smtp.mail=toyvenu@gmail.com; dkim=pass header.i=toyvenu@gmail.com Received: from mr.google.com ([10.152.112.132]) by 10.152.112.132 with SMTP id iq4mr14522836lab.28.1329730390508 (num_hops = 1); Mon, 20 Feb 2012 01:33:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vwe+gvB9Qzq8VMFQbAWRj5r/OmLzrxqQu1XMo38BGDM=; b=nOhH7/reU4yhZFpDvp9jBR4RAVrqDUUueTph3ws4ut8vvahI5SRIepZw4jYqoWzQi5 rXivN0tLc5MK5fKM6RXUyiyTIh/S30DtfE8/PSu3faWpnCfK/wiuvH/Ugl4aoUGcCoa6 f6gyptB1zLIwZ3YlgbFQlxTvqH+Zb4u3gzp3E= MIME-Version: 1.0 Received: by 10.152.112.132 with SMTP id iq4mr12088891lab.28.1329730390434; Mon, 20 Feb 2012 01:33:10 -0800 (PST) Received: by 10.152.122.239 with HTTP; Mon, 20 Feb 2012 01:33:10 -0800 (PST) In-Reply-To: <90BEEA9D-5BC2-4F2F-AF1F-6777074814FB@ag-projects.com> References: <90BEEA9D-5BC2-4F2F-AF1F-6777074814FB@ag-projects.com> Date: Mon, 20 Feb 2012 15:03:10 +0530 Message-ID: From: venu Y To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Content-Type: multipart/alternative; boundary=f46d0408d67391a42d04b961fb99 Cc: simple@ietf.org Subject: Re: [Simple] Multiple m= lines X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 09:33:13 -0000 --f46d0408d67391a42d04b961fb99 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for quick response. On Mon, Feb 20, 2012 at 2:42 PM, Sa=FAl Ibarra Corretg=E9 wrote: > Hi, > > On Feb 20, 2012, at 9:10 AM, venu Y wrote: > > > Hi all, > > > > Case: Client A wants to offer two file transfers(two m=3D lines) using > MSRP in an SIP session with client B. > > > > Client B, on receiving the offer, displays the two file names with > options (Accept/Reject) to user and waits for his response. > > > > If the user, accepts first file and didn't inform any thing about secon= d > file... then how should Client B should respond? > > > > What do you mean by "didn't inform anything"? How does that 200 OK look > like? > > > 1. Should he force the user to give response to all offers at a time.. > > > > Of course, when you send the 200 OK all offered streams must be present i= n > the answer, if you want to reject a stream just set the port to 0. > > > 2. Should he wait for a stipulated time, if no response is received fro= m > user, then he should opt for a default configured behaviour. > > > > 3. Is there any provision in offer/answer model, to inform the other > party that.. > > > > one m=3D line status is ready and other m=3D line decision is in pendin= g... > > > > I don't think that's possible. What you could do, for example, is learn > the information (filename, hash, size) on the stream you don't want to > accept right now, reject it and send a re-INVITE later, adding a new stre= am > with that data and direction 'recvonly', thus *requesting* that the remot= e > party sends you that file. > > > Regards, > > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects > > > > --=20 With Regards Venu 93484 89945 toyvenu@gmail.com --f46d0408d67391a42d04b961fb99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for quick response.

On Mon, Feb 20= , 2012 at 2:42 PM, Sa=FAl Ibarra Corretg=E9 <saul@ag-projects.com> wrote:=
Hi,

On Feb 20, 2012, at 9:10 AM, venu Y wrote:

> Hi all,
>
> Case: Client A wants to offer two file transfers(two m=3D lines) using= MSRP in an SIP session with client B.
>
> Client B, on receiving the offer, displays the two file names with opt= ions (Accept/Reject) to user and waits for his response.
>
> If the user, accepts first file and didn't inform any thing about = second file... then how should Client B should respond?
>

What do you mean by "didn't inform anything"? How does = that 200 OK look like?

> 1. Should he force the user to give response to all offers at a time..=
>

Of course, when you send the 200 OK all offered streams must be prese= nt in the answer, if you want to reject a stream just set the port to 0.

> 2. Should he wait for a stipulated time, if no response is received fr= om user, then he should opt for a default configured behaviour.
>
> 3. Is there any provision in offer/answer model, to inform the other p= arty that..
>
> one m=3D line status is ready and other m=3D line decision is in pendi= ng...
>

I don't think that's possible. What you could do, for example= , is learn the information (filename, hash, size) on the stream you don'= ;t want to accept right now, reject it and send a re-INVITE later, adding a= new stream with that data and direction 'recvonly', thus *requesti= ng* that the remote party sends you that file.


Regards,

--
Sa=FAl Ibarra Corretg=E9
AG Projects






--
With Regards=
Venu
93484 89945

--f46d0408d67391a42d04b961fb99-- From saul@ag-projects.com Mon Feb 20 02:39:58 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479A321F8748; Mon, 20 Feb 2012 02:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQMwSbYcCMJt; Mon, 20 Feb 2012 02:39:57 -0800 (PST) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8323421F8715; Mon, 20 Feb 2012 02:39:57 -0800 (PST) Received: by mail.sipthor.net (Postfix, from userid 5001) id ABB3FB01B8; Mon, 20 Feb 2012 11:39:55 +0100 (CET) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id EA913B019B; Mon, 20 Feb 2012 11:39:42 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-Priority: 3 In-Reply-To: <4FE9598F0B7E440FBC143D124F4437A6@codalogic> Date: Mon, 20 Feb 2012 11:39:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1434D56D-2E9D-42A9-94C5-71C88D1D94BA@ag-projects.com> References: <20120214215439.F2F5172F1F1@rfc-editor.org><4F3AE1D5.5030505@nostrum.com><4F3D43C0.2040005@stpeter.im><088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> <042B7D73-556C-41AB-AC54-E59942D7575C@ag-projects.com> <4FE9598F0B7E440FBC143D124F4437A6@codalogic> To: Pete Cordell X-Mailer: Apple Mail (2.1084) Cc: geopriv@ietf.org, rai@ietf.org, simple@ietf.org Subject: Re: [Simple] [RAI] [Geopriv] PLEASE TAKE NOTE: Fwd: [TechnicalErrata Reported] RFC4480 (3121) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 10:39:58 -0000 Hi Pete, >=20 > I don't know anything about PIDF, but I know a bit about XML Schema = and I > think there might be some mis-understanding of what namespace=3D"##other"> does. >=20 > If you have a schema fragment like: >=20 > > > > type=3D"empty" /> > type=3D"empty" /> > type=3D"empty" /> > maxOccurs=3D"unbounded" processContents=3D"lax"/> > > > >=20 > Then the following would _violate_ the schema: >=20 > >=20 > The reason is that the element is specifying that the = extension > must be in an-other namespace, not the namespace specified by the = schema. >=20 > Something like the following would be OK: >=20 > > > >=20 > So as I understand it, I believe this change could > break existing implementations that choose to use schema > validation. Whether, given the state of current implementation, that = is a issue in practice is a matter for the group. >=20 You are right, this was what was pointed out, that the change would make = validating the current schema erroneous. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From pete@tech-know-ware.com Mon Feb 20 02:36:31 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117BB21F8742 for ; Mon, 20 Feb 2012 02:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.227 X-Spam-Level: * X-Spam-Status: No, score=1.227 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MIME_8BIT_HEADER=0.3, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42mQjd0smNU9 for ; Mon, 20 Feb 2012 02:36:26 -0800 (PST) Received: from codalogic.com (codalogic.com [94.136.60.219]) by ietfa.amsl.com (Postfix) with ESMTP id D612D21F873B for ; Mon, 20 Feb 2012 02:36:25 -0800 (PST) Received: (qmail 30025 invoked from network); 20 Feb 2012 10:36:24 +0000 Received: from unknown (HELO codalogic) (95.146.193.111) by codalogic.com with (RC4-MD5 encrypted) SMTP; 20 Feb 2012 10:36:24 +0000 Message-ID: <4FE9598F0B7E440FBC143D124F4437A6@codalogic> From: "Pete Cordell" To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= , "Hannes Tschofenig" References: <20120214215439.F2F5172F1F1@rfc-editor.org><4F3AE1D5.5030505@nostrum.com><4F3D43C0.2040005@stpeter.im><088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> <042B7D73-556C-41AB-AC54-E59942D7575C@ag-projects.com> X-Unsent: 1 Date: Mon, 20 Feb 2012 10:36:03 -0000 X-Vipre-Scanned: 003FDC34002D30003FDD81 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Mailman-Approved-At: Mon, 20 Feb 2012 06:38:29 -0800 Cc: geopriv@ietf.org, rai@ietf.org, simple@ietf.org Subject: Re: [Simple] [RAI] [Geopriv] PLEASE TAKE NOTE: Fwd: [TechnicalErrata Reported] RFC4480 (3121) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 10:36:31 -0000 Original Message From: "Saúl Ibarra Corretgé" > On Feb 16, 2012, at 7:26 PM, Hannes Tschofenig wrote: >> >> I am curious: Why you do schema validation? >> >> When you receive a PIDF document in a SIP message then you will have to >> parse it. Since we put any namespace="##other" statements in nearly all >> our schema files I am curious what you actually going to learn from the >> validation since almost everything validates without error. > Well, I like to do schema validation to al least know that the document > doesn't violate the specified structure. Yes, you may put whatever you > want > in ##other, but PIDF does define certain elements, and those will not fall > in the ##other bucket, so those should be validated. I don't know anything about PIDF, but I know a bit about XML Schema and I think there might be some mis-understanding of what does. If you have a schema fragment like: Then the following would _violate_ the schema: The reason is that the element is specifying that the extension must be in an-other namespace, not the namespace specified by the schema. Something like the following would be OK: So as I understand it, I believe this change could break existing implementations that choose to use schema validation. Whether, given the state of current implementation, that is a issue in practice is a matter for the group. HTH, Pete Cordell Codalogic Ltd Interface XML to C++ the easy way using C++ XML data binding to convert XSD schemas to C++ classes. Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com for more info From ben@nostrum.com Mon Feb 20 06:56:34 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335A321F865B; Mon, 20 Feb 2012 06:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLhgOBwhj8Rb; Mon, 20 Feb 2012 06:56:29 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AE58321F8620; Mon, 20 Feb 2012 06:56:29 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q1KEuP4O087385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Feb 2012 08:56:26 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell X-Priority: 3 In-Reply-To: <1434D56D-2E9D-42A9-94C5-71C88D1D94BA@ag-projects.com> Date: Mon, 20 Feb 2012 08:56:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <344A0735-EFF9-4606-AE10-BED9B2CAD3F8@nostrum.com> References: <20120214215439.F2F5172F1F1@rfc-editor.org><4F3AE1D5.5030505@nostrum.com><4F3D43C0.2040005@stpeter.im><088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> <042B7D73-556C-41AB-AC54-E59942D7575C@ag-projects.com> <4FE9598F0B7E440FBC143D124F4437A6@codalogic> <1434D56D-2E9D-42A9-94C5-71C88D1D94BA@ag-projects.com> To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-Mailer: Apple Mail (2.1257) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: geopriv@ietf.org, rai@ietf.org, Pete Cordell , simple@ietf.org Subject: Re: [Simple] [RAI] [Geopriv] PLEASE TAKE NOTE: Fwd: [TechnicalErrata Reported] RFC4480 (3121) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 14:56:34 -0000 Taking this back to the original question: It looks like we have a rough consensus that the proposed change is not = backward's compatible for devices that validate schemas. Does anyone = disagree at this point?=20 What does that mean for the question of fixing the schema via an = erratum? On Feb 20, 2012, at 4:39 AM, Sa=FAl Ibarra Corretg=E9 wrote: > Hi Pete, >=20 >>=20 >> I don't know anything about PIDF, but I know a bit about XML Schema = and I >> think there might be some mis-understanding of what > namespace=3D"##other"> does. >>=20 >> If you have a schema fragment like: >>=20 >> >> >> >> > type=3D"empty" /> >> > type=3D"empty" /> >> > type=3D"empty" /> >> > maxOccurs=3D"unbounded" processContents=3D"lax"/> >> >> >> >>=20 >> Then the following would _violate_ the schema: >>=20 >> >>=20 >> The reason is that the element is specifying that the = extension >> must be in an-other namespace, not the namespace specified by the = schema. >>=20 >> Something like the following would be OK: >>=20 >> >> >> >>=20 >> So as I understand it, I believe this change could >> break existing implementations that choose to use schema >> validation. Whether, given the state of current implementation, that = is a issue in practice is a matter for the group. >>=20 >=20 > You are right, this was what was pointed out, that the change would = make validating the current schema erroneous. >=20 >=20 > Regards, >=20 > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From martin.thomson@gmail.com Mon Feb 20 10:41:10 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5CA21F8600; Mon, 20 Feb 2012 10:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.892 X-Spam-Level: X-Spam-Status: No, score=-3.892 tagged_above=-999 required=5 tests=[AWL=-2.152, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkMQHHcQ3QGg; Mon, 20 Feb 2012 10:41:07 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2E821F85D7; Mon, 20 Feb 2012 10:41:06 -0800 (PST) Received: by bkuw12 with SMTP id w12so5504287bku.31 for ; Mon, 20 Feb 2012 10:41:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gg0fGXOFV0QhSFech0/dXEqIvL7NZkM7ooau22KEJT4=; b=B7wLkgPzzXTqJeXC/D8aJBXc8qD4O7nJDfD69gRr3WT4tmsx3/cQtuZpY+VslhKYvZ Gj41wS+B3+bfWZa2udqPNH/VX9fsUD1jm9h/VZAXBAT+WhVUMyyDQbC/k6qYjNkz6mwQ YVAphgCD+q1fFtljiOBmdf7m9/J1Byr02U75c= MIME-Version: 1.0 Received: by 10.204.132.84 with SMTP id a20mr4400111bkt.21.1329763265620; Mon, 20 Feb 2012 10:41:05 -0800 (PST) Received: by 10.204.241.81 with HTTP; Mon, 20 Feb 2012 10:41:05 -0800 (PST) In-Reply-To: <344A0735-EFF9-4606-AE10-BED9B2CAD3F8@nostrum.com> References: <20120214215439.F2F5172F1F1@rfc-editor.org> <4F3AE1D5.5030505@nostrum.com> <4F3D43C0.2040005@stpeter.im> <088E6E10-C3B3-4AC8-B02F-A5165AA5115E@ag-projects.com> <042B7D73-556C-41AB-AC54-E59942D7575C@ag-projects.com> <4FE9598F0B7E440FBC143D124F4437A6@codalogic> <1434D56D-2E9D-42A9-94C5-71C88D1D94BA@ag-projects.com> <344A0735-EFF9-4606-AE10-BED9B2CAD3F8@nostrum.com> Date: Mon, 20 Feb 2012 10:41:05 -0800 Message-ID: From: Martin Thomson To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Cc: geopriv@ietf.org, rai@ietf.org, simple@ietf.org Subject: Re: [Simple] [Geopriv] [RAI] PLEASE TAKE NOTE: Fwd: [TechnicalErrata Reported] RFC4480 (3121) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 18:41:10 -0000 On 20 February 2012 06:56, Ben Campbell wrote: > What does that mean for the question of fixing the schema via an erratum? Add a note to the erratum: The "lunch" element cannot be used without risk of the document being rejected. --Martin p.s. Non-existence of a midday meal is consistent with some workplace policies. However, in some jurisdictions such a policy may be considered illegal according to workplace legislation. From miguel.a.garcia@ericsson.com Fri Feb 24 03:11:47 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A5E21F87C4 for ; Fri, 24 Feb 2012 03:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.307 X-Spam-Level: X-Spam-Status: No, score=-10.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auBRvKq8Wr38 for ; Fri, 24 Feb 2012 03:11:46 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2F77521F876C for ; Fri, 24 Feb 2012 03:11:24 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-a6-4f47705b66be Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A4.A2.01970.B50774F4; Fri, 24 Feb 2012 12:11:24 +0100 (CET) Received: from [159.107.51.96] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Fri, 24 Feb 2012 12:11:23 +0100 Message-ID: <4F47705A.4030203@ericsson.com> Date: Fri, 24 Feb 2012 12:11:22 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [Simple] Simple chat. Gen-ART comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 11:11:47 -0000 When Suresh did the Gen-ART review of the SIMPLE chat draft, he had two comments. Here is a proposal for his resolution. Please comment, especially if you disagree or can improve the text: 1) REQ-3: It is unclear why this is separate from REQ-2. In my reading, REQ-2 already covers REQ-3. I propose to make REQ-2 a requirement to identify the sender and REQ-3 a requirement to identify the recipient. My proposal: REQ-2: A conference participant must be able to determine the identifier of the sender of received instant messages. Note that the actual identifier depends on the one which was used by the sender when he or she joined the conference. REQ-3: A conference participant must be able to determine the identifier of the recipient of received messages. For instance, the recipient of the message might be the entire conference or a single participant of the conference (i.e., a private message). Note that the actual identifier may depend on the one which was used by the recipient when he or she joined the conference. 2) Section 6.1 This sentence is not clear. Can you clarify/reword. "Having the header of the Message/CPIM wrapper only in the first chunk, the MSRP switch MUST track the Message-Id until the last chunk of the message has been distributed." I agree that the sentence is only clear to the MSRP savvy guy, and I don't like the "MUST track", because it does not really have a clear action to a normative statement, so I propose to write instead: Note that the MSRP switch does not need to wait for the reception of the complete MSRP chunk or MSRP message before it starts the distribution to the rest of the participants. Instead, once the MSRP switch has received the headers of the Message/CPIM wrapper it SHOULD start the distribution process. When forwarding chunked messages as soon as they are received, the Message/CPIM wrapper is only present in the first chunk. Subsequent chunks will contain the rest of the message, but not the Message/CPIM headers. Therefore, an MSRP message that receives a subsequent message may face challenges in determining the correct list of recipients of the message. An MSRP switch that uses this fast forwarding procedure MUST temporarily store the Message-Id of the MSRP message to correlate the different chunks, as well as it MUST temporarily store the list of recipients to which the first chunk was delivered. The MSRP switch SHOULD forward subsequent chunks only to those recipients of the first chunk, except if the MSRP switch has knowledge that one of the recipients of a first chunk has dropped from the chat. This avoids new participants who joined the chat when the first chunk has been distributed to receive subsequent chunks that would otherwise need to be discarded. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ben@nostrum.com Fri Feb 24 06:56:20 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3163921F87E4 for ; Fri, 24 Feb 2012 06:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXqVWsQq9FAd for ; Fri, 24 Feb 2012 06:56:19 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 72C8021F867A for ; Fri, 24 Feb 2012 06:56:19 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q1OEuFaS013559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Feb 2012 08:56:16 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <4F47705A.4030203@ericsson.com> Date: Fri, 24 Feb 2012 08:56:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F47705A.4030203@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1257) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] Simple chat. Gen-ART comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 14:56:20 -0000 On Feb 24, 2012, at 5:11 AM, Miguel A. Garcia wrote: > When Suresh did the Gen-ART review of the SIMPLE chat draft, he had = two comments. Here is a proposal for his resolution. Please comment, = especially if you disagree or can improve the text: >=20 > 1) REQ-3: It is unclear why this is separate from REQ-2. In my = reading, > REQ-2 already covers REQ-3. >=20 > I propose to make REQ-2 a requirement to identify the sender and REQ-3 = a requirement to identify the recipient. My proposal: >=20 >=20 > REQ-2: A conference participant must be able to determine the > identifier of the sender of received instant messages. Note > that the actual identifier depends on the one which was used > by the sender when he or she joined the conference. >=20 > REQ-3: A conference participant must be able to determine the > identifier of the recipient of received messages. For > instance, the recipient of the message might be the entire > conference or a single participant of the conference (i.e., = a > private message). Note that the actual identifier may = depend > on the one which was used by the recipient when he or she > joined the conference. >=20 I'm fine with REQ-2. For REQ-3, who is the participant? Are we talking = about the sender, the recipient, or someone else? In the case of a = sender, the operative word is probably "select" rather than "determine". >=20 >=20 > 2) Section 6.1 >=20 > This sentence is not clear. Can you clarify/reword. >=20 > "Having the header of the Message/CPIM wrapper only in the first = chunk, > the MSRP switch MUST track the Message-Id until the last chunk of the > message has been distributed." >=20 >=20 >=20 > I agree that the sentence is only clear to the MSRP savvy guy, and I = don't like the "MUST track", because it does not really have a clear = action to a normative statement, so I propose to write instead: >=20 > Note that the MSRP switch does not need to wait for the reception of > the complete MSRP chunk or MSRP message before it starts the > distribution to the rest of the participants. Instead, once the = MSRP > switch has received the headers of the Message/CPIM wrapper it = SHOULD > start the distribution process. >=20 > When forwarding chunked messages as soon as they are received, the > Message/CPIM wrapper is only present in the first chunk. Subsequent > chunks will contain the rest of the message, but not the = Message/CPIM > headers. Therefore, an MSRP message that receives a subsequent > message may face challenges in determining the correct list of > recipients of the message. An MSRP _switch_ that receives a subsequent _chunk_... > An MSRP switch that uses this fast > forwarding procedure MUST temporarily store the Message-Id of the > MSRP message to correlate the different chunks, as well as it MUST > temporarily store the list of recipients to which the first chunk = was > delivered. The MSRP switch SHOULD forward subsequent chunks only to > those recipients of the first chunk, except if the MSRP switch has > knowledge that one of the recipients of a first chunk has dropped > from the chat. This avoids new participants who joined the chat = when > the first chunk has been distributed to receive subsequent chunks > that would otherwise need to be discarded. >=20 It's possible, by the way, for Message/CPIM header fields to occur in a = chunk other than the first one. It's highly unlikely, but I can envision = a message with a huge Message/CPIM header splitting the header, or a = message that got interrupted very shortly after starting. In any given = field should occur only once, but even an individual field could get = split across chunks--particularly in the case of the recipient list. >=20 >=20 >=20 > /Miguel >=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From miguel.a.garcia@ericsson.com Sat Feb 25 01:19:38 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA6921F84C8 for ; Sat, 25 Feb 2012 01:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.314 X-Spam-Level: X-Spam-Status: No, score=-10.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EajD6M015+-U for ; Sat, 25 Feb 2012 01:19:37 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D879621F84EA for ; Sat, 25 Feb 2012 01:19:36 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-e7-4f48a7a74f95 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0F.80.27041.7A7A84F4; Sat, 25 Feb 2012 10:19:35 +0100 (CET) Received: from [159.107.51.96] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Sat, 25 Feb 2012 10:19:34 +0100 Message-ID: <4F48A7A6.2070500@ericsson.com> Date: Sat, 25 Feb 2012 10:19:34 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ben Campbell References: <4F47705A.4030203@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Simple chat. Gen-ART comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 09:19:38 -0000 Hi Ben, thanks for the comments. See inline replies. On 24/02/2012 15:56, Ben Campbell wrote: > > On Feb 24, 2012, at 5:11 AM, Miguel A. Garcia wrote: > >> When Suresh did the Gen-ART review of the SIMPLE chat draft, he had two comments. Here is a proposal for his resolution. Please comment, especially if you disagree or can improve the text: >> >> 1) REQ-3: It is unclear why this is separate from REQ-2. In my reading, >> REQ-2 already covers REQ-3. >> >> I propose to make REQ-2 a requirement to identify the sender and REQ-3 a requirement to identify the recipient. My proposal: >> >> >> REQ-2: A conference participant must be able to determine the >> identifier of the sender of received instant messages. Note >> that the actual identifier depends on the one which was used >> by the sender when he or she joined the conference. >> >> REQ-3: A conference participant must be able to determine the >> identifier of the recipient of received messages. For >> instance, the recipient of the message might be the entire >> conference or a single participant of the conference (i.e., a >> private message). Note that the actual identifier may depend >> on the one which was used by the recipient when he or she >> joined the conference. >> > > I'm fine with REQ-2. For REQ-3, who is the participant? Are we talking about the sender, the recipient, or someone else? In the case of a sender, the operative word is probably "select" rather than "determine". Good point. The requirement is not about any participant, but a recipient of a message. In a chat room with multiple participants, if I send you a private message, the requirement is that you (the recipient) must be able to determine who sent it (REQ-2) and to who is addressed (me: it's a private message, rather than the whole chat room) (REQ-3). I will replace "conference participant" with "recipient of an instant message in a chat room". > >> >> >> 2) Section 6.1 >> >> This sentence is not clear. Can you clarify/reword. >> >> "Having the header of the Message/CPIM wrapper only in the first chunk, >> the MSRP switch MUST track the Message-Id until the last chunk of the >> message has been distributed." >> >> >> >> I agree that the sentence is only clear to the MSRP savvy guy, and I don't like the "MUST track", because it does not really have a clear action to a normative statement, so I propose to write instead: >> >> Note that the MSRP switch does not need to wait for the reception of >> the complete MSRP chunk or MSRP message before it starts the >> distribution to the rest of the participants. Instead, once the MSRP >> switch has received the headers of the Message/CPIM wrapper it SHOULD >> start the distribution process. >> >> When forwarding chunked messages as soon as they are received, the >> Message/CPIM wrapper is only present in the first chunk. Subsequent >> chunks will contain the rest of the message, but not the Message/CPIM >> headers. Therefore, an MSRP message that receives a subsequent >> message may face challenges in determining the correct list of >> recipients of the message. > > An MSRP _switch_ that receives a subsequent _chunk_... Fixed. > >> An MSRP switch that uses this fast >> forwarding procedure MUST temporarily store the Message-Id of the >> MSRP message to correlate the different chunks, as well as it MUST >> temporarily store the list of recipients to which the first chunk was >> delivered. The MSRP switch SHOULD forward subsequent chunks only to >> those recipients of the first chunk, except if the MSRP switch has >> knowledge that one of the recipients of a first chunk has dropped >> from the chat. This avoids new participants who joined the chat when >> the first chunk has been distributed to receive subsequent chunks >> that would otherwise need to be discarded. >> > > It's possible, by the way, for Message/CPIM header fields to occur in a chunk other than the first one. It's highly unlikely, but I can envision a message with a huge Message/CPIM header splitting the header, or a message that got interrupted very shortly after starting. In any given field should occur only once, but even an individual field could get split across chunks--particularly in the case of the recipient list. This is a good point too. So, I am now trying to reflect that the Message/CPIM header typically occurs in the first chunk. And rather than talking of the "first chunk", I am talking of "initial chunks" and "subsequent chunks". Here is the proposed text: When forwarding chunked messages as soon as they are received, the Message/CPIM wrapper is only present at the beginning of the message, typically within the first chunk. Subsequent chunks will contain the rest of the message, but not the Message/CPIM headers. Therefore, an MSRP switch that receives a subsequent message may face challenges in determining the correct list of recipients of the message. An MSRP switch that uses this fast forwarding procedure MUST temporarily store the Message-Id of the MSRP message to correlate the different chunks, as well as it MUST temporarily store the list of recipients to which the initial chunks were delivered. The MSRP switch SHOULD forward subsequent chunks only to those recipients who were sent the initial chunks, except if the MSRP switch has knowledge that one of the recipients of the initial chunks has dropped from the chat room. This behavior also avoids new participants who joined the chat room when the first chunk has been distributed to receive subsequent chunks that would otherwise need to be discarded. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Sat Feb 25 01:57:50 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28EB621F8682 for ; Sat, 25 Feb 2012 01:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.32 X-Spam-Level: X-Spam-Status: No, score=-10.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HK+sD+nGl0Y for ; Sat, 25 Feb 2012 01:57:49 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3306621F867F for ; Sat, 25 Feb 2012 01:57:49 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-3d-4f48b09b6108 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D8.E7.01970.B90B84F4; Sat, 25 Feb 2012 10:57:47 +0100 (CET) Received: from [159.107.51.96] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Sat, 25 Feb 2012 10:57:47 +0100 Message-ID: <4F48B09A.5030707@ericsson.com> Date: Sat, 25 Feb 2012 10:57:46 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Simple WG , Christer Holmberg Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [Simple] Simple chat: Christer's comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 09:57:50 -0000 I am now addressing comments that Christer did in his Gen-ART review. I want to thank Christer for sending these comments. See his comments below and my inline reply. > Minor issues: > > - The second paragraph of section 7.1 says that a NICKNAME request > MUST contain a Use-Nickname header, but in the sixth paragraph the > inclusion is a SHOULD. That is not totally correct. The second paragraph says: "The NICKNAME request MUST include a new Use-Nickname header" whereas the sixth paragraph tries to say (but apparently failed) in which methods the Use-Nickname header could be included: The Use-Nickname header field carries a nickname string, and SHOULD be included in the NICKNAME requests. I proposed to add "only" to clarify the paragraph: The Use-Nickname header field carries a nickname string and SHOULD only be included in NICKNAME requests. > > - It is not clearly indicated whether the Use-Nickname header is > allowed for other methods than NICKNAME. I think it should be clear now, see previous comment. > - Section 8 does not specify whether there are SDP offer/answer > considerations/restrictions associated with the new attribute. For > example: -- Must the attribute tokens in an answer be a subset of the > tokens in an offer? -- Can an SDP answer contain an attribute if the > offer didn't? -- If a user sends a new SDP offer within a session, can > the token values be modified? What does it mean if the attribute is > not present in a new SDP offer? > Good point. I have reworded these paragraphs, let me know what you think: The 'chatroom' attribute merely indicates the capabilities supported and allowed by the local policy. This attribute is not a negotiation subject to the SDP offer/answer model, but instead a declaration. Therefore, a 'chatroom' attribute included in an SDP answer does not need to be a subset of the 'chatroom' attribute included in its corresponding SDP offer. It is also possible that an SDP answer contains a 'chatroom' attribute even if its corresponding SDP offer did not include it. On doing subsequent SDP offer/answer exchanges pertaining to the same session, the 'chatroom' attribute MAY be modified with respect an earlier SDP offer/answer exchange. The new value of this attribute indicate the current support and local policy, meaning that some restrictions can apply now or might have been removed. I have also added a normative reference to RFC 3264 in the above text and other parts of the draft where the SDP offer/answer model is mentioned. > > Nits/editorial comments: > > - Sometimes the document talks about "multi-party chat", "multi-party > conference", "conference", and "chat room". Would it be possible to > use more consistant terminology? > Yes. Wherever possible, i.e., in most places, I am trying to use "chat room". There are places where is not possible, for example, when we refer to the conference event package, conference framework, conference focus, etc. But I guess this solves your concern. > - Requirements > -- REQ-4: Isn't this requirement already covered by > REQ-3? No, these are different. Req-3 claims for a mechanism for the recipient of a message to determine whether the receive message is private or regular. Req-4 claims for the a mechanism to send private messages. > -- REQ-6: Change "progress" to "duration" or "length". Done. > > - There is no definition/reference for "roster". > Roster is a not a technical term, therefore, it is not subject to be define in this draft. BR, Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From christer.holmberg@ericsson.com Sun Feb 26 11:05:28 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EF421F850B for ; Sun, 26 Feb 2012 11:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.153 X-Spam-Level: X-Spam-Status: No, score=-10.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbC0+4RXvMbA for ; Sun, 26 Feb 2012 11:05:27 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 63F9421F8505 for ; Sun, 26 Feb 2012 11:05:26 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-c1-4f4a827664aa Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 91.AF.27041.6728A4F4; Sun, 26 Feb 2012 20:05:26 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.31]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Sun, 26 Feb 2012 20:05:25 +0100 From: Christer Holmberg To: Miguel Garcia A , Simple WG Date: Sun, 26 Feb 2012 20:05:25 +0100 Thread-Topic: Simple chat: Christer's comments Thread-Index: Aczzo+2AsOEbrer4Q42K66WMko+EnABFIftE Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3F48C5E5@ESESSCMS0356.eemea.ericsson.se> References: <4F48B09A.5030707@ericsson.com> In-Reply-To: <4F48B09A.5030707@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] Simple chat: Christer's comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2012 19:05:28 -0000 Hi, >> I am now addressing comments that Christer did in his Gen-ART review. I >> want to thank Christer for sending these comments. > >>See his comments below and my inline reply. > >> Minor issues: >> >> - The second paragraph of section 7.1 says that a NICKNAME request >> MUST contain a Use-Nickname header, but in the sixth paragraph the >> inclusion is a SHOULD. > > That is not totally correct. The second paragraph says: > > "The NICKNAME request MUST include a new Use-Nickname header" > > > whereas the sixth paragraph tries to say (but apparently failed) in which > methods the Use-Nickname header could be included: > > The Use-Nickname header field carries a > nickname string, and SHOULD be included in the NICKNAME requests. > > I proposed to add "only" to clarify the paragraph: > > The Use-Nickname header field carries a > nickname string and SHOULD only be included in NICKNAME requests. Why not "MUST only"? >> - It is not clearly indicated whether the Use-Nickname header is >> allowed for other methods than NICKNAME. > > I think it should be clear now, see previous comment. > >> - Section 8 does not specify whether there are SDP offer/answer >> considerations/restrictions associated with the new attribute. For >> example: -- Must the attribute tokens in an answer be a subset of the >> tokens in an offer? -- Can an SDP answer contain an attribute if the >> offer didn't? -- If a user sends a new SDP offer within a session, can >> the token values be modified? What does it mean if the attribute is >> not present in a new SDP offer? >> > > Good point. I have reworded these paragraphs, let me know what you think: > > The 'chatroom' attribute merely indicates the capabilities supported > and allowed by the local policy. This attribute is not a negotiation > subject to the SDP offer/answer model, but instead a declaration. > Therefore, a 'chatroom' attribute included in an SDP answer does not > need to be a subset of the 'chatroom' attribute included in its > corresponding SDP offer. It is also possible that an SDP answer > contains a 'chatroom' attribute even if its corresponding SDP offer > did not include it. Would it be better to say that it is allowed to included a 'chatroom' attri= bute in an SDP answer, even if the associated offer did not contain one? That way you actually describe answerer behavior, rather than just indicati= ng that the offerer may receive the attribute in an answer. > On doing subsequent SDP offer/answer exchanges pertaining to the same > session, the 'chatroom' attribute MAY be modified with respect an > earlier SDP offer/answer exchange. The new value of this attribute > indicate the current support and local policy, meaning that some > restrictions can apply now or might have been removed. It is good, but to be really clear I would also suggest the following sente= nce - where I'll let you add the end of the sentence :) "If the 'chatroom' attribute is not included in a subsequent SDP offer/answ= er, it indicates that ." > I have also added a normative reference to RFC 3264 in the above text and > other parts of the draft where the SDP offer/answer model is mentioned. > >> >> Nits/editorial comments: >> >> - Sometimes the document talks about "multi-party chat", "multi-party >> conference", "conference", and "chat room". Would it be possible to >> use more consistant terminology? >> > > Yes. > > Wherever possible, i.e., in most places, I am trying to use "chat room". > There are places where is not possible, for example, when we refer to the > conference event package, conference framework, conference focus, etc. > But I guess this solves your concern. Yes. >> - Requirements >> -- REQ-4: Isn't this requirement already covered by >> REQ-3? > > No, these are different. Req-3 claims for a mechanism for the recipient > of a message to determine whether the receive message is private or regul= ar. > > Req-4 claims for the a mechanism to send private messages. Correct. My misstake. >> -- REQ-6: Change "progress" to "duration" or "length". > > Done. > >> >> - There is no definition/reference for "roster". >> > > > Roster is a not a technical term, therefore, it is not subject to be defi= ne in this draft. Ok. Regards, Christer= From miguel.a.garcia@ericsson.com Mon Feb 27 00:26:23 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB24E21F8503 for ; Mon, 27 Feb 2012 00:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.326 X-Spam-Level: X-Spam-Status: No, score=-10.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wfo8DFMqg1vT for ; Mon, 27 Feb 2012 00:26:23 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D4F5A21F8501 for ; Mon, 27 Feb 2012 00:26:22 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-a8-4f4b3e2c69f4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D7.29.01970.C2E3B4F4; Mon, 27 Feb 2012 09:26:21 +0100 (CET) Received: from [159.107.24.214] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Mon, 27 Feb 2012 09:26:19 +0100 Message-ID: <4F4B3E2A.7010701@ericsson.com> Date: Mon, 27 Feb 2012 09:26:18 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Christer Holmberg References: <4F48B09A.5030707@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F48C5E5@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3F48C5E5@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Simple chat: Christer's comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 08:26:24 -0000 Hi Christer, see some inline replies. On 26/02/2012 20:05, Christer Holmberg wrote: > > Hi, > >>> - The second paragraph of section 7.1 says that a NICKNAME request >>> MUST contain a Use-Nickname header, but in the sixth paragraph the >>> inclusion is a SHOULD. >> >> That is not totally correct. The second paragraph says: >> >> "The NICKNAME request MUST include a new Use-Nickname header" >> >> >> whereas the sixth paragraph tries to say (but apparently failed) in which >> methods the Use-Nickname header could be included: >> >> The Use-Nickname header field carries a >> nickname string, and SHOULD be included in the NICKNAME requests. >> >> I proposed to add "only" to clarify the paragraph: >> >> The Use-Nickname header field carries a >> nickname string and SHOULD only be included in NICKNAME requests. > > Why not "MUST only"? Because I want to leave an open door for someone who has a very good reason to add this header to a method different than NICKNAME. > >>> - It is not clearly indicated whether the Use-Nickname header is >>> allowed for other methods than NICKNAME. >> >> I think it should be clear now, see previous comment. >> >>> - Section 8 does not specify whether there are SDP offer/answer >>> considerations/restrictions associated with the new attribute. For >>> example: -- Must the attribute tokens in an answer be a subset of the >>> tokens in an offer? -- Can an SDP answer contain an attribute if the >>> offer didn't? -- If a user sends a new SDP offer within a session, can >>> the token values be modified? What does it mean if the attribute is >>> not present in a new SDP offer? >>> >> >> Good point. I have reworded these paragraphs, let me know what you think: >> >> The 'chatroom' attribute merely indicates the capabilities supported >> and allowed by the local policy. This attribute is not a negotiation >> subject to the SDP offer/answer model, but instead a declaration. >> Therefore, a 'chatroom' attribute included in an SDP answer does not >> need to be a subset of the 'chatroom' attribute included in its >> corresponding SDP offer. It is also possible that an SDP answer >> contains a 'chatroom' attribute even if its corresponding SDP offer >> did not include it. > > Would it be better to say that it is allowed to included a 'chatroom' attribute in an SDP answer, even if the associated offer did not contain one? > > That way you actually describe answerer behavior, rather than just indicating that the offerer may receive the attribute in an answer. I have now replaced the last sentence of the proposed new text with this one: Consequently, an SDP answer MAY contain a 'chatroom' attribute even if its corresponding SDP offer did not include it. > >> On doing subsequent SDP offer/answer exchanges pertaining to the same >> session, the 'chatroom' attribute MAY be modified with respect an >> earlier SDP offer/answer exchange. The new value of this attribute >> indicate the current support and local policy, meaning that some >> restrictions can apply now or might have been removed. > > It is good, but to be really clear I would also suggest the following sentence - where I'll let you add the end of the sentence :) > > "If the 'chatroom' attribute is not included in a subsequent SDP offer/answer, it indicates that." Ok, this is the new sentence: If the 'chatroom' attribute is not included in a subsequent SDP offer/answer, but is corresponding MSRP stream is still in place, it indicates that support for the procedures indicated in this document are disabled. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From christer.holmberg@ericsson.com Mon Feb 27 00:42:50 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3E821F855F for ; Mon, 27 Feb 2012 00:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.18 X-Spam-Level: X-Spam-Status: No, score=-10.18 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiFrtYKvXPQf for ; Mon, 27 Feb 2012 00:42:49 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 42D0C21F851D for ; Mon, 27 Feb 2012 00:42:49 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-76-4f4b42073cf3 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CB.BA.27041.7024B4F4; Mon, 27 Feb 2012 09:42:48 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.31]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Mon, 27 Feb 2012 09:42:47 +0100 From: Christer Holmberg To: Miguel Garcia A Date: Mon, 27 Feb 2012 09:42:06 +0100 Thread-Topic: Simple chat: Christer's comments Thread-Index: Acz1KXthSee2uYf5SyOYp2daoaxb2QAAY1gQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3F3A4E2D@ESESSCMS0356.eemea.ericsson.se> References: <4F48B09A.5030707@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F48C5E5@ESESSCMS0356.eemea.ericsson.se> <4F4B3E2A.7010701@ericsson.com> In-Reply-To: <4F4B3E2A.7010701@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Simple chat: Christer's comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 08:42:50 -0000 Hi,=20 >>>> - The second paragraph of section 7.1 says that a NICKNAME request=20 >>>> MUST contain a Use-Nickname header, but in the sixth paragraph the=20 >>>> inclusion is a SHOULD. >>> >>> That is not totally correct. The second paragraph says: >>> >>> "The NICKNAME request MUST include a new Use-Nickname header" >>> >>> >>> whereas the sixth paragraph tries to say (but apparently failed) in=20 >>> which methods the Use-Nickname header could be included: >>> >>> The Use-Nickname header field carries a >>> nickname string, and SHOULD be included in the NICKNAME requests. >>> >>> I proposed to add "only" to clarify the paragraph: >>> >>> The Use-Nickname header field carries a >>> nickname string and SHOULD only be included in NICKNAME requests. >> >> Why not "MUST only"? > > Because I want to leave an open door for someone who has a very good reas= on to add this header to a method different than NICKNAME. Fair enough, but if that is the intention then I don't think SHOULD fits ei= ther. Instead, I rather write that this specification only defines the usag= e of the header for NICKNAME, and if someone wants to use it with another m= ethod the usage must be defined in a dedicated spec. >>>> - It is not clearly indicated whether the Use-Nickname header is >>>> allowed for other methods than NICKNAME. >>> >>> I think it should be clear now, see previous comment. >>> >>>> - Section 8 does not specify whether there are SDP offer/answer >>>> considerations/restrictions associated with the new attribute. For >>>> example: -- Must the attribute tokens in an answer be a subset of the >>>> tokens in an offer? -- Can an SDP answer contain an attribute if the >>>> offer didn't? -- If a user sends a new SDP offer within a session, can >>>> the token values be modified? What does it mean if the attribute is >>>> not present in a new SDP offer? >>>> >>> >>> Good point. I have reworded these paragraphs, let me know what you thin= k: >>> >>> The 'chatroom' attribute merely indicates the capabilities supporte= d >>> and allowed by the local policy. This attribute is not a negotiati= on >>> subject to the SDP offer/answer model, but instead a declaration. >>> Therefore, a 'chatroom' attribute included in an SDP answer does no= t >>> need to be a subset of the 'chatroom' attribute included in its >>> corresponding SDP offer. It is also possible that an SDP answer >>> contains a 'chatroom' attribute even if its corresponding SDP offer >>> did not include it. >> >> Would it be better to say that it is allowed to included a 'chatroom' at= tribute in an SDP answer, even if the associated offer did not contain one? >> >> That way you actually describe answerer behavior, rather than just indic= ating that the offerer may receive the attribute in an answer. > > I have now replaced the last sentence of the proposed new text with this = one: > > Consequently, an SDP answer MAY contain a 'chatroom' > attribute even if its corresponding SDP offer did not include > it. Ok. >>> On doing subsequent SDP offer/answer exchanges pertaining to the sa= me >>> session, the 'chatroom' attribute MAY be modified with respect an >>> earlier SDP offer/answer exchange. The new value of this attribute >>> indicate the current support and local policy, meaning that some >>> restrictions can apply now or might have been removed. >> >> It is good, but to be really clear I would also suggest the following se= ntence - where I'll let you add the end of the sentence :) >> >> "If the 'chatroom' attribute is not included in a subsequent SDP offer/a= nswer, it indicates that." > > Ok, this is the new sentence: > > If the 'chatroom' attribute is not included in a > subsequent SDP offer/answer, but is corresponding MSRP stream > is still in place, it indicates that support for the > procedures indicated in this document are disabled. Good. Regards, Christer From miguel.a.garcia@ericsson.com Mon Feb 27 01:44:27 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8500421F8472 for ; Mon, 27 Feb 2012 01:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.332 X-Spam-Level: X-Spam-Status: No, score=-10.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-bZPcq65g0a for ; Mon, 27 Feb 2012 01:44:26 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6DE21F8467 for ; Mon, 27 Feb 2012 01:44:26 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-ef-4f4b50799012 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6F.21.01970.9705B4F4; Mon, 27 Feb 2012 10:44:25 +0100 (CET) Received: from [159.107.24.214] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Mon, 27 Feb 2012 10:44:24 +0100 Message-ID: <4F4B5077.30005@ericsson.com> Date: Mon, 27 Feb 2012 10:44:23 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Christer Holmberg References: <4F48B09A.5030707@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F48C5E5@ESESSCMS0356.eemea.ericsson.se> <4F4B3E2A.7010701@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F3A4E2D@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3F3A4E2D@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Simple chat: Christer's comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 09:44:27 -0000 On 27/02/2012 9:42, Christer Holmberg wrote: > Fair enough, but if that is the intention then I don't think SHOULD > fits either. Instead, I rather write that this specification only > defines the usage of the header for NICKNAME, and if someone wants to > use it with another method the usage must be defined in a dedicated > spec. What about this text? As indicated earlier, this specification defines a new MSRP header field: "Use-Nickname". The Use-Nickname header field carries a nickname string. This specification defines the usage of the Use-Nickname header field in NICKNAME requests. If need arises, usages of the Use-Nickname header field in other MSRP methods should be specified separately. BR, Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From christer.holmberg@ericsson.com Mon Feb 27 01:56:16 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B7521F861C for ; Mon, 27 Feb 2012 01:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.186 X-Spam-Level: X-Spam-Status: No, score=-10.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zMbsA5A628Q for ; Mon, 27 Feb 2012 01:56:15 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D8EE021F85D0 for ; Mon, 27 Feb 2012 01:56:14 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-db-4f4b533da4dd Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 87.50.27041.D335B4F4; Mon, 27 Feb 2012 10:56:13 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.31]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 27 Feb 2012 10:56:13 +0100 From: Christer Holmberg To: Miguel Garcia A Date: Mon, 27 Feb 2012 10:55:32 +0100 Thread-Topic: Simple chat: Christer's comments Thread-Index: Acz1NGO29zz8RPdGTbugPSYezd19UgAAVkRA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3F3A4F02@ESESSCMS0356.eemea.ericsson.se> References: <4F48B09A.5030707@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F48C5E5@ESESSCMS0356.eemea.ericsson.se> <4F4B3E2A.7010701@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F3A4E2D@ESESSCMS0356.eemea.ericsson.se> <4F4B5077.30005@ericsson.com> In-Reply-To: <4F4B5077.30005@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Simple chat: Christer's comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 09:56:16 -0000 Hi,=20 >> Fair enough, but if that is the intention then I don't think SHOULD=20 >> fits either. Instead, I rather write that this specification only=20 >> defines the usage of the header for NICKNAME, and if someone wants to=20 >> use it with another method the usage must be defined in a dedicated=20 >> spec. > > What about this text? > > As indicated earlier, this specification defines a new MSRP header > field: "Use-Nickname". The Use-Nickname header field carries a > nickname string. This specification defines the usage of the > Use-Nickname header field in NICKNAME requests. If need arises, > usages of the Use-Nickname header field in other MSRP methods should > be specified separately. Looks good. Regards, Christer